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1.0  INTRODUCTION 


People  concerned  with  the  evaluation  of  software  products  are  acutely 
aware  of  the  need  for  automated  support  tools  and  methods.  If  software  quali¬ 
ty  could  be  objectively  and  automatically  assessed  early  in  the  life-cycle, 
provisions  could  be  taken  to  assure  that  quality  goals  are  being  met.  This 
could  ultimately  reduce  life-cycle  costs  and  result  in  a  more  reliable  and 
maintainable  product. 

Prior  work  sponsored  by  the  Rome  Air  Development  Center  (RADC) ,  has  devel¬ 
oped  the  Software  Quality  Measurement  Framework,  a  means  to  specify  quality 
goals  and  measure  software  quality.  This  effort  enhances  that  framework  by 
identifying  metrics  that  can  be  used  on  software  designs,  automating  these 
design  metrics,  and  providing  a  methodology  for  using  metrics,  embedded  in 
automated  design  tools,  during  the  early  phases  of  the  software  development 
life-cycle.  An  experimental  design  tool,  Design  Aids  for  Real-Time  Systems 
(DARTS),  is  used  to  illustrate  the  metrics  and  methodology.  In  addition, 
design  metrics  in  the  Ada2  context  are  also  considered. 


1.1  REPORT  ORGANIZATION 


This  report  is  organized  as  follows.  Section  1  provides  background,  defi¬ 
nitions,  and  an  overview  of  the  research  program.  Section  2  includes  detailed 
technical  data  and  research  results  related  to  the  identification  and  develop¬ 
ment  of  automated  design  metrics.  Section  3  describes  a  methodology  developed 
for  using  automated  design-aid  tools  and  metrics  in  support  of  an  integrated 
software  development  environment.  Section  4  summarizes  the  conclusions  of 
this  effort  and  Section  5  provides  a  list  of  recommendations  for  future 
research. 

The  appendices  supply  A)  a  list  of  acronyms,  B)  DARTS  trees  for  the  exam¬ 
ple  designs,  C)  DARTS  design  trees  of  the  Halstead  metric  implementation,  D) 
design  trees  of  the  McCabe  metric,  and  E)  DARTS  data-flow  tables  for  the 
Experiment  Controller  example.  A  list  of  references  and  a  bibliography  of 
sources  used  are  also  included. 
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1.2  HISTORICAL  PERSPECTIVE 


High  quality  software  is  of  interest  to  both  the  software  engineering  com¬ 
munity  and  its  users.  As  evidenced  by  the  Software  Initiative  [DoD82a] , 
recently  renamed  Software  Technology  for  Adaptable  and  Reliable  Systems 
(STARS)  [DoD  83] ,  which  by  charter  will  develop  tools  and  methods  to  increase 
the  quality  of  DoD  software,  software  quality  will  no  longer  be  tested-in,  but 
rather  be  required  and  designed-in.  An  important  part  of  the  Initiative  is 
the  development  of  metrics  to  measure  the  quality  of  both  the  software  devel¬ 
opment  process  and  software  products.  With  some  advantageous  foresight  into 
this  problem,  the  RADC  has  been  sponsoring  research  in  this  technical  area,  in 
particular  the  development  of  the  Software  Quality  Framework  [McC  77]  which 
identifies  both  user-  and  management-oriented  techniques  for  quantifying  soft¬ 
ware  product  quality. 


1.2.1  The  Software  Quality  Framework 

The  initial  Software  Quality  Framework  effort,  sponsored  by  RADC  and  Elec¬ 
tronic  Systems  Division  (ESD)  under  contract  F30602-76-C-0147 ,  addressed  two 
major  issues,  software  quality  specification  and  measurement.  This  effort 
identified  11  factors  in  a  hierarchical  framework  for  acquisition  managers  to 
use  to  specify,  predict,  and  control  software  quality.  The  following  defi¬ 
nitions  are  provided. 

Software:  the  programs  and  documentation  associated  with  and  resulting 
from  the  software  development  process. 

Quality:  a  general  term  applicable  to  any  trait  or  characteristic, 

whether  individual  or  generic;  a  distinguishing  attribute  which  indicates 
a  degree  of  excellence  or  identifies  the  basic  nature  of  something. 

Factor:  a  condition  or  characteristic  which  actively  contributes  to  the 
quality  of  the  software.  The  following  rules  apply  to  the  set  of  soft¬ 
ware  quality  factors: 

A  condition  or  characteristic  which  contributes  to  software  quality. 

A  user-related  characteristic. 

A  relative  characteristic  between  software  products. 

Criteria:  attributes  of  the  software  or  software-production  process  by 
which  the  factor  can  be  judged  and  defined.  The  following  rules  apply  to 
the  criteria: 
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Attributes  of  the  software  or  software  products  of  the  development 
process;  i.e.,  criteria  are  software-oriented  while  factors  are 
user-oriented. 

May  display  a  hierarchical  relationship  with  subcriteria. 

May  affect  more  than  one  factor. 

Metrics;  quantitative  measures  of  the  software  attributes  related  to  the 
quality  factors.  The  measures  may  be  objective  or  subjective. 

The  relationship  of  factors,  criteria,  and  metrics  is  illustrated  in 
Figure  1.  McCall's  framework  identifies  11  prime  factors  (correctness,  effi¬ 
ciency,  integrity,  usability,  testability,  flexibility,  reusability,  maintain¬ 
ability,  reliability,  portability,  and  interoperability)  which  correspond  to 
user-oriented  attributes.  Corresponding  criteria  were  established  as  soft¬ 
ware-product-oriented  attributes.  The  criteria  have  a  fourfold  purpose; 

1.  To  refine  the  factor. 

2.  To  help  describe  relationships  between  factors. 

3.  To  establish  a  one-to-one  relationship  between  criteria  and  metrics. 

4.  To  create  a  natural  hierarchy  in  the  framework  for  factors  in  software 
quality. 

In  1978,  RADC  and  the  U.S.  Army  Computer  Systems  Command  continued  this 
work  with  a  Metrics  Enhancement  Study  under  contract  number  F30602-78-C-0216. 
The  results  of  the  study,  reported  in  [McC  79] ,  refined  the  results  of  the 
initial  study  and  produced  a  measurement  manual  for  acquisition  managers 
describing  how  to  apply  the  framework  in  the  acquisition  process. 


In  1979,  another  contract,  number  F30602-79-C-0267,  was  awarded  to  develop 
an  Automated  Measurement  Tool  (AMT) .  The  AMT,  delivered  to  the  Air  Force  in 
September  of  1981,  automates  the  collection  of  specific  metric  data  from  pro¬ 
grams  written  in  COBOL,  and  provides  a  quality  metric  assessment. 

In  1980,  RADC  sponsored  additional  refinements  to  the  framework  under  con¬ 
tract  F30602-80-C-0265  to  formulate  and  validate  metrics  for  interoperability 
and  reusability.  This  effort  resulted  in  a  slightly  rearranged  framework  [Boe 
83b]  and  a  new  measurement  manual  [Boe  83a]  for  acquisition  managers. 

In  1982,  RADC  sponsored  this  effort,  under  contract  F30602-82-C-0130 ,  to 
improve  the  framework  by  identifying  metrics  useful  in  the  early  phases  of  the 
software  development  life-cycle.  This  was  motivated  by  evidence  that  it  is 
easier  and  more  cost-efficient  to  correct  software  at  the  requirements  and 
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Figure  1.  The  Software  Quality  Framework 


design  phases.  Where  most  of  the  metrics  previously  developed  were  oriented 
toward  manual  collection  of  data  from  software  code,  this  approach  emphasizes 
automated  software  design  tools  for  data  collection  from  encoded  software 
design  media. 

Design  tools  for  the  DoD  will  in  the  future  be  increasingly  focused  on  the 
Ada  language  and  Ada  Programming  Support  Environments  (APSEs) .  Some  Ada-spe¬ 
cific  design  tools  already  exist,  such  as  PDL/Ada  [Weg  82]  and  Byron  [Gor  83] . 
Other  design-aid  tools  will  become  available  as  part  of  the  DoD  STARS  program. 
Part  of  this  effort  has  investigated  the  evaluation  of  Ada  designs  with  a 
design  metric. 


1.2.2  Metrics  of  Software  Quality 

The  collection  of  metric  data  during  software  design  can  provide  early 
visibility  of  the  quality  of  tne  developing  software  product,  and  better  esti¬ 
mates  of  its  size  and  complexity. 

Software  quality  is  that  collection  of  traits  or  characteristics  which 
imply  a  degree  of  excellence  or  goodness  of  a  software  product.  This  research 
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builds  on  the  contributions  of  many  other  software  engineering  efforts,  most 
notably  [McC  77]  and  [Boe  83b] ,  which  have  defined  and  refined  a  framework  for 
quantifying  software  quality. 


According  to  the  groundrules  set  in  the  framework,  software  quality  is 
measured  by  the  absence,  presence,  or  degree  of  some  identifiable  software 
product  attribute.  A  premise  upon  which  this  research  is  based  requires  soft¬ 
ware  designs  to  be  viewed  as  viable  and  measurable  software  products,  and  the 
criteria,  which  can  be  captured  from  software  design  media,  must  be  defined. 
Design  metrics  should  not  be  dependent  on  the  design  medium  used  but  the  medi¬ 
um  must  have  the  necessary  information  content.  The  information  necessary  for 
each  depends  on  the  metric  chosen.  The  capture  of  this  information  can  be 
automated  through  the  use  of  design-aid  tools.  Automation  improves  both  the 
efficiency  of  the  process  and  the  consistency  of  the  data  gathered. 

Automated  design  evaluation  would  be  useful  to  designers,  program  manag¬ 
ers,  and  program  office  personnel  alike.  Designers  would  be  able  to  quickly 
compare  competing  designs  and  objectively  choose  the  best  one.  Managers  could 
more  easily  track  the  software's  development  and  estimate  more  accurately  its 
eventual  size  and  completion  date.  Similarly,  program  office  personnel  would 
have  more  visibility  into  the  status  and  quality  of  the  product  for  which  they 
are  responsible. 

A  more  detailed  description  of  the  tools  and  techniques  necessary  to  use 
design  metrics  effectively  is  included  as  Section  3  of  this  report. 


1.2.3  Automated  Software  Design  Tools 

Software  at  the  design  phase  exists  in  various  product  forms,  most  common¬ 
ly  as  flowcharts,  program  design  languages  [Cai  75],  or  other  design  media 
(e.g. ,  [CSDL80]  and  [Tei  77]).  This  product  is  an  abstraction  of  the  eventual 
code,  and  as  such,  can  be  evaluated  as  a  predictor  of  the  quality  of  the  soft¬ 
ware  code  end-product.  Early  indicators  of  quality  are  desirable  and  have  the 
potential  to  increase  reliability  and  decrease  costs.  In  a  subsequent  sec¬ 
tion,  this  topic  is  considered  with  respect  to  automated  design  media  which, 
in  the  authors'  opinion,  have  many  advantages  over  classical  design  media 
(e.g. ,  flowcharts) . 

1.2. 3.1  Software  Design  Media 

A  software  design  medium  is  any  form  of  notation  (textual  or  graphical) 
for  representing  and  communicating  software  designs.  Design  media  aid  soft¬ 
ware  development  personnel  by  assisting  with  the  following  functions  [szu  80] . 

1.  Representation  of  the  system  and  software  architecture  at  various  stag¬ 
es  of  development. 


INTRODUCTION  5 


2.  Enforcement  of  the  use  of  design  standards. 

3.  Implementation  planning. 

4.  Performance  and  quality  assessment. 

5.  Management  visibility  and  control  during  implementation. 

Most  currently  available  design  media  are  deficient  in  one  or  more  of  the 
above  areas  and  few  are  automated.  In  the  following  sections  a  brief  survey 
of  current  automated  design  media  is  included.  This  survey  is  not  complete, 
but  does  illustrate  the  available  automated  design  media  technology. 

1.2. 3. 2  Automated  Program  Design  Languages 

Various  automated  program  design  languages  (PDLs)  are  available.  These 
structured  English  processors  produce  various  output  to  replace  traditional 
flowcharts.  These  media  are  easier  to  read  and  modify,  and  can  be  easily 
adjusted  for  any  desired  level  of  detail.  Some  current  examples  follow. 

The  Caine,  Farber  and  Gordon  PDL  [Cai  77]  is  a  tool  to  aid  in  designing 
and  documenting  a  program  or  system  of  programs.  A  design  in  PDL  is  written 
in  structured  English  then  submitted  to  the  PDL  processor  with  control  infor¬ 
mation  to  form  procedures.  The  output  is  a  working  design  document  consisting 
of  a  detailed  table  of  contents,  a  listing  of  formatted  procedures,  a  call 
tree,  and  a  cross  reference  of  the  procedure  calls.  This  tool  evolved  from 
Caine  and  Gordon's  earlier  work  [Cai  75]. 

PDL/ Ada  [Weg  82]  was  developed  for  use  with  the  Ada  language.  It  uses  a 
proper  subset  of  the  Ada  language. 

Byron  [Gor  83]  was  developed  by  Intermetrics  specifically  for  use  with  the 
Ada  language,  although  its  author  claims  that  its  use  is  not  restricted  to 
Ada.  Byron  is  based  on  Ada  such  that  any  legitimate  Ada  program  is  also  a 
legitimate  Byron  specification.  It  differs  from  Ada  in  two  respects.  Byron 
allows  additional  information  about  a  declaration  to  be  associated  with  it. 
Second,  Byron  tools  can  produce  useful  output  from  incomplete  specifications. 
These  advantages  over  pure  Ada  are  discussed  in  more  detail  in  Section  2.5. 

1.2. 3. 3  Automated  Requirements  and  Design  Languages 

The  Problem  Statement  Language/  Problem  Statement  Analyzer  (PSL/PSA)  [Tei 
77] ,  was  developed  to  improve  the  process  of  preparing  and  analyzing  software 
specifications.  This  automated  tool  provides  a  medium  which  uses  objects, 
relationships  between  objects,  and  properties  of  objects  to  specify  soft¬ 
ware/system  processes.  PSA  checks  consistency  of  the  database  and  provides  a 
variety  of  reports. 
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1.2. 3. 4  Design  Aids  for  Real-Time  Systems  (DARTS) 

Design  Aids  for  Real-Time  Systems  (DARTS)  (Fur  8l]  [CSDL82]  is  a  tool 
developed  at  The  Charles  Stark  Draper  Laboratory,  Inc.  (CSDL)  that  assists  in 
defining  embedded  computer  systems  through  tree-structured  graphics,  documen¬ 
tation  support,  and  various  analysis  features.  These  analysis  features  pro¬ 
vide  both  static  and  dynamic  software  design  feedback  which  can  potentially 
aid  in  the  production  of  efficient,  reliable,  and  maintainable  software  sys¬ 
tems. 

DARTS  uses  a  mix  of  hierarchy,  control  and  communications  primitives,  and 
data  structures  to  represent  real-time  systems.  Requirements  are  expressed  as 
a  functional  hierarchy  and  designs  as  a  tree-structured  hierarchy  of  communi¬ 
cating  processes. 

Although  developed  to  represent  real-time  interactions,  DARTS  can  be  used 
for  both  real-time  and  non-real-time  systems.  Through  a  friendly,  menu-or¬ 
iented  interface,  a  user  can  build  an  encoded  representation  of  a  system;  per¬ 
form  data-flow  checking;  generate  simulations  of  the  design  to  estimate 
response  time,  throughput,  and  utilization;  create  a  variety  of  data  tables 
and  graphical  tree-structured  output  in  a  variety  of  sizes;  and,  most  recent¬ 
ly,  request  an  automated  quality  assessment  of  a  software  design. 

DARTS  has  been  used  throughout  this  research  project  as  a  documentation 
aid  and  development  test-bed  for  the  software  design  quality  metrics  described 
in  the  next  section.  Throughout  this  report,  DARTS  trees  and  tables  appear  as 
illustrations. 


1.3  PROJECT  OVERVIEW 


This  research  project  is  part  of  RADC's  Software  Quality  Measurement  Pro¬ 
gram.  It  has  demonstrated  that  automatic  and  objective  measures  of  software 
design  quality  can  be  captured  from  encoded  software  design  media.  In  addi¬ 
tion,  a  methodology  has  been  provided,  useful  for  designers  and  program  office 
personnel  alike,  for  incorporating  automatic  design  quality  assessment  tools 
into  the  acquisition  and  development  of  future  software  products. 

Various  metrics  have  shown  utility  as  indicators  of  design  quality,  but 
few  have  been  automated  and  integrated  into  a  design-aid  tool.  Two  metrics 
were  chosen  for  implementation  and  integration  into  an  available  design-aid 
tool.  These  metrics,  though  added  to  the  DARTS  analysis  capability,  are  not 
constrained  to  this  particular  tool.  To  demonstrate  this,  one  metric  is  shown 
to  be  applicable  to  Ada  designs. 
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The  objectives  of  this  research  program  were  to 


1.  develop  and  validate  software  design  quality  metrics,  and 

2.  develop  a  methodology,  consistent  with  the  RADC  Software  Quality  Frame¬ 
work,  for 

a.  evaluating  competitive  software  designs, 

b.  estimating  software  project  planning  parameters, 

c.  monitoring  software  product  quality. 


1.3.2  Technical  Approach 

To  accomplish  these  objectives,  the  tasks  listed  in  the  following  section 
were  defined.  These  tasks  are  described  as  stated  in  the  contractual  state¬ 
ment  of  work,  and  a  summary  statement  for  each  task  follows  the  description. 
Detailed  technical  data  corresponding  to  these  tasks  are  referenced  and  follow 
in  the  remainder  of  this  report. 

•  Task  4.1.1  Develop  Design  Phase  Software  Quality  Metrics 

In  this  task,  design  phase-oriented  metrics  shall  be  developed  and 
demonstrated  to  enhance  the  Software  Quality  Framework.  These  metrics 
shall  include,  but  not  be  limited  to,  software  science  metrics. 

In  this  task,  a  survey  of  the  literature  was  performed,  the  detailed 
results  of  which  are  described  in  Section  2.2.  The  sources  are 
included  in  the  bibliography.  Design  oriented  metrics  were  examined 
and  shown  to  be  compatible  with  the  RADC  Software  Quality  Framework. 
The  Framework  was  also  reexamined  in  the  light  of  dividing  the  total 
design  effort  into  architectural  and  detailed  design  phases.  These 
results  are  documented  in  Table  5. 

•  Task  4.1.2  Automate  Design  Quality  Metrics 

In  this  task,  design  quality  metrics  which  are  suitable  for  auto¬ 
mation  shall  be  identified.  In  addition,  at  least  two  metrics  shall  be 
automated  using  the  DARTS  tool.  Those  metrics  not  suitable  for  auto¬ 
mation  shall  also  be  identified  and  manual  procedures  for  collecting 
the  data  shall  be  documented. 
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In  this  task,  metrics  suitable  for  automation  were  identified  and  those 
that  were  not  were  listed.  These  results  are  summarized  in  Table  5  and 
Table  6.  Two  metrics  were  chosen  as  candidates  for  automation  using 
DARTS.  The  Halstead  metric  technique  was  implemented  after  require¬ 
ments  and  design  details  were  resolved.  The  McCabe  metric  was  also 
implemented.  Implementation  independent  details  are  included  in  Sec¬ 
tion  2.2.  Requirements  and  Design  information  for  the  DARTS  implemen¬ 
tation  of  both  metrics  is  included  in  Section  2.3. 

Task  4. 1.2.1  Apply  Metrics  To  Software  Designs 

In  this  task,  the  metrics  shall  be  applied  to  a  set  of  designs  for 
which  actual  code  exists. 

The  literature  search  turned  up  many  examples  of  code  to  use  for  this 
validation  stage.  In  some  instances,  code  representing  both  good  and 
bad  coding  form  was  available  for  functionally  equivalent  units.  These 
units  were  translated  into  a  DARTS  design  and  then  evaluated  by  both 
the  Halstead  and  McCabe  metrics.  The  DARTS  trees  for  these  designs 
appear  in  Appendix  B  and  the  metric  analysis  is  discussed  in  Section 
2.4. 


In  order  to  extend  this  technique  to  other  design  media,  the  Hal¬ 
stead  metrics  were  applied  to  Ada  designs.  The  results  of  this  task 
are  presented  in  Section  2.5. 

Task  4. 1.2.2  Verify  Metrics 

In  this  task,  the  utility  of  the  metrics  as  estimators  of  quality 
and  size  (where  appropriate)  shall  be  verified. 

Empirical  data  has  been  generated  for  a  small  sample  of  problems. 
These  results  are  compared  with  subjective  assessments,  and  previously 
published  data.  The  results  of  this  task  are  summarized  in  Section 
2.4. 

Task  4. 1.2. 3  Calibrate  New  DARTS  Metrics 

In  this  task,  the  metrics  under  development  shall  be  calibrated,  if 
necessary,  to  improve  the  measurement  technique. 

A  simple  calibration  was  performed  on  the  Halstead  metric.  Using  the 
results  of  Task  4. 1.2.1,  the  design  was  modified  to  generate  results 
consistent  with  those  found  in  the  literature.  No  calibration  of  the 
McCabe  metric  was  performed. 
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Task  4.1.4  Develop  a  Methodology  for  Using  Design  Metrics 

In  this  task,  a  methodology  shall  be  developed  to  address  the  fol¬ 
lowing  issues. 

1.  evaluate  competing  designs 

2.  estimate  various  project  planning  parameters 

3.  monitor  the  quality  of  a  software  project 

This  methodology  shall  be  consistent  with  the  objectives  of  the  Soft¬ 
ware  Quality  Framework. 

The  results  of  this  task  are  the  topic  of  Section  3.  In  that  section, 
a  method  is  described  for  using  Halstead's  metrics  in  the  early  design 
phase  to  estimate  the  size  of  an  implementation  and  hence  the  project 
cost  and  schedule. 
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2.0  ON  THE  DEVELOPMENT,  USE,  AND  AUTOMATION  OF  DESIGN  METRICS 


Software  metrics  can  be  useful  within  the  context  of  an  integrated  soft¬ 
ware  engineering  environment.  The  purpose  of  this  section  is  to  describe  the 
characteristics  of  such  an  environment. 


2.1  A  CONTEXT  FOR  METRICS  IN  THE  DEVELOPMENT  PROCESS 


The  software  development  process  consists  of  personnel  engaged  in  software 
engineering  for  the  production  of  software  products.  Boehm  [Boe  81,  pp.16] 
defines  software  engineering  as 

”...  the  application  of  science  and  mathematics  by  which  the  capabilities  of 
computer  equipment  are  made  useful  to  man  via  computer  programs,  procedures, 
and  associated  documentation." 

This  definition  implies  skill,  innovation,  and  intuition  on  the  part  of  the 
software  engineer,  as  well  as  the  support  tools  that  the  engineer  uses.  Mod¬ 
ern  programming  methods  like  top-down,  stepwise  decomposition,  information 
hiding,  and  modular  programming  have  improved  programming  style  and  automated 
tools  have  lessened  the  burden  of  documentation,  program  generation,  config¬ 
uration  management,  and  analysis.  Yet  even  today,  few  tool  packages  exist 
that  are  integrated  into  a  portable  product  which  is  useful  throughout  the 
development  process. 

The  term  "integrated"  is  stressed  to  distinguish  it  from  "bundled".  Soft¬ 
ware  tools  have  traditionally  evolved  from  the  bundling  concept.  That  is, 
tools  that  function  well  individually  have  been  used  together  with  other  simi¬ 
lar  tools.  Data  interfaces  between  tools,  when  they  exist,  are  set  up  to  pro¬ 
vide  a  continuum  of  data  flow  and  information  from  one  tool  to  the  next. 
Often,  error-prone  human  users  are  these  interfaces,  and  the  success  of  this 
translation  is  dependent  on  the  skill  of  the  user.  Information  can  be  lost, 
errors  introduced,  and  product  quality  suffers.  Manpower  used  in  this  opera¬ 
tion  is  often  wasted.  By  providing  integrated  tools,  which  by  design  directly 
interface  to  each  other,  the  chances  for  a  better  quality  product  are 
increased  and  manpower  is  reduced.  Providing  such  a  toolset  is  one  goal  of 
the  STARS  program.  This  research  supports  that  goal. 

The  basic  elements  of  an  integrated  software  engineering  environment  are 
skilled  personnel,  tools,  and  management  and  business  practices  which  contrib¬ 
ute  to  the  development  and  maintenance  of  software  products.  This  environment 
provides  the  context  for  all  of  the  activities  associated  with  software  prod- 
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uct  development  during  its  life-cycle.  The  life-cycle  of  a  software  product 
begins  at  the  conception  of  a  required  capability  and  ends  with  the  software’s 
eventual  retirement  from  use.  In  many  DoD  applications  this  life-cycle  is 
easily  fifteen  to  twenty  years  long. 

In  the  sections  to  follow,  a  software  life-cycle  model  is  described  which 
depends  on  automated  support  tools,  including  software  metrics.  This  model  is 
presented  here  to  define  a  frame  of  reference  for  the  succeeding  discussion. 


2.1.1  A  Software  Development  Process  Model 


Although  this  research  emphasizes  the  design  phase  of  a  software  product, 
it  is  important  to  characterize  the  total  picture  to  see  where  it  fits  in.  In 
this  section,  a  software  development  process  model  is  described.  This  model 
takes  into  account  both  the  software  products  (i.e.,  documentation,  code,  sup¬ 
port  tools,  etc.)  and  the  management  activities  (i.e.,  planning,  organizing, 
staffing,  controlling,  and  assessing).  Coordination  of  engineering  and  man¬ 
agement  talent  creates  quality  software.  Integrated  software  tools  support 
both  of  these  disciplines  over  the  life-cycle  of  the  product.  The  scope  of 
this  research  extends  to  both  of  these  domains.  Quality  metrics  can  provide 
an  assessment  of  the  quality  of  the  software  product,  and  indirectly,  the 
quality  of  the  process.  These  issues  will  be  discussed  further  in  succeeding 
sections. 


2.1.2  The  Software  Development  Life  Cycle 

The  software  development  life-cycle  can  be  simply  divided  into  6  phases. 


Software  Requirements  Specification 
Architectural  Design  (Top  Level  or  Preliminary) 


Detailed  Design 


Code  and  Unit  Test 


Integration  and  Acceptance  Test 


Operations  and  Maintenance 


It  is  often  difficult  to  determine  where  one  phase  begins  or  ends  so  the 
following  guidelines  are  offered  to  precisely  define  the  start  and  end  points 
of  each  phase,  the  corresponding  software  products,  and  management  activities. 
This  model  is  generally  applicable  to  medium  (i.e.,  1  to  4  man-years)  or  large 
scale  (i.e.,  greater  than  4  man-years)  development  efforts. 


Start  Requirements  Specification  Phase 

This  phase  assumes  that  a  prior  system  specification  activity  has 
occurred  to  determine  an  appropriate  division  of  basic  requirements 
made  between  hardware  and  software.  This  requires  a  definition  of  the 
system  architecture,  man-machine  interface,  and  quality  goals,  and  a 
plan  of  basic  milestones,  activities,  and  schedules.  The  input  to  this 
first  software  development  phase  is  generally  a  verbal  statement  of  the 
user's  software  needs.  This  activity  should  clearly  define  what  the 
software  is  to  accomplish. 

•  Activities  -  Planning,  requirements  formalization  and  consistency 
checking . 

•  Outputs  -  Preliminary  plans,  requirements  document. 

End  Requirements  Phase,  Begin  Architectural  Design  Phase 

This  endpoint  is  often  reached  by  a  formal  requirements  review  and 
acceptance  activity.  The  Architectural  Design  Phase,  often  refered  to 
as  Top  Level  or  Preliminary,  should  produce  a  functional  architecture 
which  is  sufficiently  detailed  in  function,  performance  and  interface 
definitions,  to  allow  both  users  and  designers  to  be  confident  that 
requirements  can  be  met  and  the  design  implemented.  Development  data, 
sufficient  for  product  and  process  metrics,  may  be  collected  on  avail¬ 
able  documentation.  Support  tools,  necessary  for  the  effort,  should  be 
acquired  or  developed. 

•  Activities  -  Architectural  design,  planning. 

•  Outputs  -  Detailed  development  plans,  architectural  design  docu¬ 
ment. 

End  Architectural  Design  Phase,  Begin  Detailed  Design  Phase 

This  endpoint  is  often  reached  by  a  Preliminary  Design  Review 
activity.  It  may  be  formal  or  informal. 

•  Activities  -  Software  component  architecture  definition,  module 
design,  data  base  design. 

•  Outputs  -  Detailed  design  specifications  for  each  module,  data  base 
specifications,  preliminary  test  and  integration  plans,  draft 
user's  manual,  product  measures,  and  process  measures. 

End  Detailed  Design  Phase,  Start  Code/Unit  Test  Phase 
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This  endpoint  is  reached  by  a  Critical  Design  Review  activity.  The 
review,  or  walkthrough,  can  be  done  at  the  module  or  program  level. 

•  Activities  -  Develop  code  and  test  each  module  according  to  stand¬ 
ards  set  in  development  plan.  Verify  completeness  and  provide 
requirements  traceability.  Configuration  manage  modules.  Complete 
test,  acceptance  and  integration  plans,  and  user's  manual. 

•  Outputs  -  Verified  and  tested  modules,  approved  acceptance  plan, 
product  measures,  and  process  measures. 

5.  End  Code/Unit  Test  Phase,  Start  Integration  and  Acceptance  Test  Phase 

This  phase  ends  when  all  modules  have  satisfied  the  unit  test 
requirements. 

•  Activities  -  integration  of  modules  into  programs,  hard¬ 
ware/software  integration  and  system  test.  Update  detailed  design 
documents  to  reflect  the  as-coded  version.  Provide  problem  report¬ 
ing  and  resolution. 

•  Outputs  -  Problem  reports,  configuration  status  reports,  as-coded 
design  document,  test  results  for  archive,  performance  data,  prod¬ 
uct  measures,  and  process  measures. 

6.  End  Integration  and  Acceptance  Test  Phase,  Start  Operations  and  Mainte¬ 
nance  Phase 

This  endpoint  is  reached  by  completion  of  the  Acceptance  Test 
activity.  The  product  is  delivered  to  the  user  and  installed.  The 
product  may  include:  documentation,  reports,  development  standards, 
support  tools  used  to  develop  the  software,  development  data,  test 
results  and  procedures  as  well  as  the  code.  Training  may  be  provided 
as  well  as  any  warranty  service. 

•  Activities  -  Installation,  support,  training. 

•  Outputs  -  All  deliverables. 


2.1.3  Using  Metrics  During  Software  Development 

The  Software  Quality  Framework  has  provided  a  language  and  structure  for 
identifying  software  quality  goals  as  well  as  providing  some  metrics  of  soft¬ 
ware  product  and  process  criteria.  The  previous  section  established  start  and 
endpoints  for  phases  within  the  software  process  life-cycle  and  listed  various 
products,  development  data,  and  process  attributes  which  can  potentially  be 
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evaluated  by  some  measurement  tool  based  on  the  ideas  stated  in  the  Software 
Quality  Framework.  A  subset  of  the  phases,  products,  and  applicable  metrics 
is  summarized  in  Table  1. 

Table  1.  Summary  of  Phases,  Products,  and  Metrics 


Life 

Cycle 

Activity 

requirements 

architectural 

design 

detailed 

design 

code  and 

unit  test 

Products 

requirements 

document 

architectural 

design 

document 

detailed 

design 

document 

code 

Metrics 

Halstead 
#  pages 

McCabe 

Halstead 
#  lines 

McCall 

• 

McCabe 

Halstead 
#  lines 

McCall 

McCabe 

Halstead 
#  lines 

McCall 

2.2  SELECTING  METRICS  FOR  AUTOMATIC  MEASUREMENT  DURING  DESIGN 


As  part  of  Task  4.1.1,  Develop  Design  Phase  Software  Quality  Metrics,  a 
survey  of  the  current  literature  on  software  metrics  was  conducted.  The  goal 
of  the  search  was  to  identify  metrics  which  are  valuable  predictors  of  soft¬ 
ware  quality  and  other  software  development  parameters,  and  can  be  applied 
during  the  design  phases.  The  results  of  the  survey  are  presented  in  Section 
2.2.1,  and  the  definitions  of  the  identified  metrics  are  presented  in  Sections 
2.2.2  and  2.2.3. 

Of  the  metrics  identified  during  the  survey,  those  which  were  compatible 
with  the  Software  Quality  Framework  were  evaluated  along  with  the  Framework 
metrics  for  application  during  the  design  phases  and  automated  data  col¬ 
lection.  Section  2.2.4  discusses  the  criteria  that  make  a  metric  suitable  for 
use  during  the  design  phases,  and  the  conditions  under  which  it  may  be  meas¬ 
ured  by  a  design  tool.  The  detailed  assessment  of  the  McCall,  McCabe,  and 
Halstead  metrics  follows  in  Section  2.2.5. 


On  The  Development,  Use,  and  Automation  of  Design  Metrics  15 


2.2.1  A  Survey  of  Recent  Metrics  Literature 


The  sources  for  the  metrics  literature  survey  are  included  in  the  Bibli¬ 
ography.  They  snow  that  much  of  the  work  going  on  with  software  metrics  today 
is  in  measuring  existing  code  with  the  Halstead  or  McCabe  metrics  and  using 
the  values  to  predict  quality  parameters  such  as  the  number  of  errors.  The 
predictions  are  then  tested  against  actual  error  data,  and  the  measurement 
techniques  are  refined.  The  results  indicate  that  the  various  Halstead  met¬ 
rics  and  the  McCabe  cyclomatic  complexity  metric  are  useful  over  different 
types  of  applications  and  implementation  languages.  These  are,  then,  prime 
candidates  for  use  during  the  design  phases. 

The  McCabe  and  Halstead  metrics  basically  measure  different  aspects  of  the 
complexity  of  software:  its  structure  and  language  use.  In  the  Software  Qual¬ 
ity  Framework  developed  by  McCall  et  al.,  the  quality  criterion  simplicity 
(the  inverse  of  complexity)  contributes  to  many  of  the  quality  factors, 
including  testability,  reliability  and  maintainability.  As  such,  it  is  a  val¬ 
uable  indicator  of  quality  during  the  design  phases.  The  Software  Quality 
Framework,  though,  covers  other  quality  factors  and  provides  metrics  to  meas¬ 
ure  the  criteria  that  affect  them.  To  make  sure  that  as  many  quality  factors 
as  possible  were  covered  during  the  design  phases,  each  McCall  metric  was  con-, 
sidered  in  detail  along  with  the  McCabe  and  Halstead  metrics  to  see  which  com¬ 
ponents  might  be  measured  during  the  design  phases,  and  which  might  be 
automated. 


2.2.2  McCabe's  Cyclomatic  Complexity  Metric 

McCabe's  cyclomatic  complexity  metric  is  based  on  the  desire  to  limit  the 
size  of  modules  in  a  software  system  so  that  they  are  easy  to  test  and  main¬ 
tain.  He  proposed  that  the  number  of  paths  through  a  module  is  a  better  meas¬ 
ure  of  testability  and  maintainability  than  just  the  number  of 
instructions/statements  in  a  module:  A  strictly  sequential  module,  with  just 
one  path,  may  be  easier  to  test  and  maintain  than  one  with  a  more  complicated 
control  structure,  even  though  the  sequential  module  is  longer.  More  paths 
through  a  module  require  more  tests,  and  McCabe  inferred  that  more  paths  will 
make  it  harder  to  locate  and  fix  errors  in  the  module  or  modify  it. 

The  metric  is  based  on  the  complexity  of  the  control  structure  of  a  module 
and  of  the  system  of  modules,  so  it  is  applicable  during  the  design  phase  as 
soon  as  that  structure  begins  to  evolve. 

2. 2. 2.1  Cyclomatic  Complexity  Metric  Definition 

The  definition  of  the  metric  is  based  on  the  following  graph  theory. 
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A  directed  graph  can  be  drawn  to  represent  the  control  flow  of  any  module. 
It  resembles  a  flowchart,  but  is  constructed  with  more  formal  rules.  Each 
group  of  statements  which  is  executed  without  a  control  transfer  becomes  a 
node,  and  the  control  transfers  become  arcs  linking  the  appropriate  nodes. 
Ideally,  all  possible  paths  through  a  module  would  be  tested.  In  practice, 
this  is  often  prohibitively  expensive  or  impossible.  (If  there  is  a  backward 
branch  in  a  module,  the  number  of  potential  paths  is  infinite).  For  a  module 
with  a  single  entry  point  and  a  single  exit  point,  a  graph  theory  result 
applies:  a  basis  for  the  graph  can  be  found,  in  terms  of  basic  paths,  which, 
in  linear  combinations,  generate  all  possible  paths  through  the  graph.  McCabe 
proposes  that  the  number  of  paths  in  the  basis  is  a  reasonable  measure  of  the 
testability  and  maintainability  of  a  module.  It  can  be  used  to  decide  when  to 
break  up  a  module,  or  to  identify  modules  which  will  be  more  difficult  to  test 
and  maintain. 

The  number  of  basic  paths  in  a  graph,  the  cyclomatic  complexity,  is 
defined  in  [McC  76]  as 

v  =  e  -  n  +  2p 

where 

n  is  the  number  of  nodes  in  a  directed  graph  of  the  program, 

e  is  the  number  of  edges  (arcs)  in  the  graph, 

p  is  the  number  of  connected  subcomponents  (modules)  of  the  program, 

and 

v  is  the  number  of  basic  paths  through  the  module. 

If  v  is  calculated  for  all  the  modules  in  a  system,  the  value  of  the  metric 
for  a  system  will  be  the  sum  of  the  values  for  the  modules  in  the  system. 

The  cyclomatic  complexity  can  also  be  obtained  from  a  visual  inspection  of 
the  program  graph,  when  the  graph  is  planar  and  connected.  In  this  case,  the 
cyclomatic  complexity  is  equal  to  the  number  of  regions  into  which  the  graph 
divides  the  plane. 

Finally,  for  structured  programs,  the  cyclomatic  complexity  is  equal  to 
the  number  of  predicates  (binary  decisions)  in  the  graph  plus  one.  (Compound 
conditions  and  multi-way  branches  are  treated  as  if  they  were  the  equivalent 
set  of  nested  single-condition  binary  branches) .  A  graph  with  no  branch 
points  leaves  the  plane  in  one  region.  Each  binary  decision  adds  another 
region  to  the  graph. 

McCabe  recognized  that  more  than  one  simple  predicate  could  be  included  in 
a  single  programming  statement,  such  as  an  IF.  Predicates  beyond  the  first 
clearly  add  complexity,  but  the  graph  would  only  show  a  single  binary  branch. 
To  account  for  the  added  complexity,  he  proposed  counting  the  number  of  simple 


On  The  Development,  Use,  and  Automation  of  Design  Metrics 


17 


\v*;yyy\i 


■  ’A’A  ■-’AV.* A ,r:  T.TTATT'.r  ".'  vr 


TT 


predicates,  rather  than  the  number  of  decision  statements.  This  amounts  to 
modelling  any  compound  condition  as  a  set  of  nested  IF  statements. 

Myers  [Mye  77]  proposed  that  the  metric  value  should  be  an  interval,  rath¬ 
er  than  a  single  number.  The  lower  bound  would  be  the  number  arrived  at  by 
using  the  number  of  decision  statements,  and  the  upper  bound  would  be  the  num¬ 
ber  arrived  at  by  using  the  number  of  simple  predicates.  This  method  has  the 
satisfying  effect  of  giving  the  metric  values  for  simple  examples  the  same 
ordering  as  their  subjective  evaluations  of  complexity. 

Neither  McCabe's  method  nor  Myers'  method  gives  different  weight  to  condi¬ 
tions  at  different  nesting  levels. 


2.2.3  Halstead's  Software  Science  Metrics 


Halstead's  Software  Science  [Hal  77]  is  a  theory  which  has  been  applied  to 
the  complex  problem  of  software  project  management.  Halstead  claimed  that 
algorithms  expressed  as  computer  programs  or  other  written  media  could  be  ana¬ 
lyzed  in  a  consistent  and  simple  manner  to  yield  indicators  or  measures  of 
quality  and  other  software  development  parameters.  Researchers  over  the  years 
have  used  this  theory  in  a  variety  of  experiments  which,  in  general,  has  shown 
it  to  have  some  degree  of  utility.  Most  experiments  to  date  have,  however, 
used  this  technique  on  software  at  the  code  stage  of  its  development.  This 
task  extends  some  previous  work  [Szu  80,  Szu  8l]  which  claimed  that  useful 
software  science  measures  could  be  derived  from  software  design  media  by 
embedding  this  metric  technique  in  an  automated  design-aid  tool. 

2. 2. 3.1  Software  Science  Definitions 

The  Halstead  technique  is  based  on  the  identification  and  enumeration  of 
four  basic  parameters  that  are  directly  available  from  the  language  used  to 
express  the  algorithm.  Other  parameters,  which  are  derived  from  these,  form 
the  set  of  software  science  metrics.  All  of  the  parameters  are  shown  in 
Table  2. 

The  four  basic  parameters  are: 

Hi  number  of  distinct  operators 
n2  number  of  distinct  operands 
Nt  total  number  of  operators 
N2  total  number  of  operands. 

According  to  Halstead,  algorithms  consist  of  operators  and  operands,  and 
nothing  else.  The  validity  of  this  claim  is  apparent  when  programming  lan¬ 
guages  are  considered,  but  when  other  forms  of  algorithm  representation  are 
used,  ambiguities  often  arise.  Languages  which  have  structured  or  abstract 
data  types  generally  cause  the  most  difficulty.  It  is  up  to  the  user  of  the 
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Halstead  technique  to  decide  which  elements  of  the  vocabulary  are  operators 
and  operands  according  to  the  vague  definitions  provided.  Operators  are  sym¬ 
bols  or  combination  of  symbols  which  affect  the  value  or  ordering  of  operands. 
Operands  are  variables  or  constants  that  the  implementation  employs. 

2. 2. 3. 2  A  Generalized  Halstead  Technique 

When  considering  adapting  the  Halstead  technique  to  a  particular  design 
medium,  the  following  procedure  is  offered. 

1.  Identify  operators  and  operands  from  the  vocabulary  of  the  language 
used  in  expressing  the  design.  This  step  is  often  the  most  crucial  and 
controversial  part  in  the  technique.  Much  prior  work  (e.g.,  [Els  78], 
[Fit  78]  ,  [Ham  82] ,  [she  83] )  has  established  evidence  that  it  is  dif¬ 
ficult  (and  sometimes  impossible)  to  determine  whether  a  vocabulary 
element  is  to  be  classified  an  operator  or  operand.  There  is  no  con¬ 
sistent  and  non-ambiguous  definition  to  use  as  a  foundation.  This  has 
caused  substantially  different  results  by  different  researchers.  It  is 
therefore  important  to  be  aware  of  these  findings  and  be  consistent 
within  an  experimental  domain. 

2-  Count  the  number  of  occurrences  of  each  operator  and  operand.  Again, 
this  step  needs  to  be  consistent.  Halstead,  for  example,  proposed  that 
each  "GO  TO  label"  be  counted  as  a  unique  operator  for  each  unique 
label,  yet  he  considered  "I?  statements"  as  n  occurrences  of  one  unique 
IF  operator. 

3.  Calculate  the  metrics  based  on  the  formulas  listed  in  Table  2. 

In  this  report,  consistent  counting  techniques  are  defined  for  the  DARTS 
design  medium  (Section  2.3.2),  and  for  Ada  as  a  design  medium  (Section  2.5.4). 
Other  examples  can  be  found  in  the  literature.  Most,  however,  consider  only 
programming  languages  like  Fortran,  PL/I,  and  IBM  assembly  language. 
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Table  2.  Halstead's  Software  Science  Metrics. 


HALSTEAD  METRIC 


DISTINCT  OPERATORS 
DISTINCT  OPERANDS 
TOTAL  OPERATORS 
TOTAL  OPERANDS 
VOCABULARY 
DESIGN  LENGTH 
ESTIMATED  LENGTH 
PERCENT  OFF 
DESIGN  VOLUME 
POTENTIAL  VOLUME 
DESIGN  LEVEL 
ESTIMATED  DESIGN  LEVEL 
INTELLIGENCE  CONTENT 
LANGUAGE  LEVEL 
ESTIMATED  LANGUAGE  LEVEL 
EFFORT 

ESTIMATED  EFFORT 


SYMBOL 


FORMULA 


n  3  Vi  +»?2 
N  =  N1  +N2 

~K - 

N  =  r>i  log27?i  +t?2  Io92t?2 


V  =»  N  log2  7? 

V*  =  rj*log2  rj* 
L  =  V*/V 
L  *  2t72/t?1N2 
I  «  LV*=  V* 

X  -  LV* 

A  An 

X  -  l2v 

E  =  V/L 

"a  a 
E  =  V/L 


2. 2. 3. 3  Interpreting  Software  Science  Metrics 

Software  science  metrics  measure  various  complexity  aspects  of  software 
components.  The  following  discussion  provides  an  interpretation  of  some  of 
the  more  usable  metrics  defined  in  Table  2. 

The  Length  (N)  is  roughly  equivalent  to  the  conventional  count  of  executa¬ 
ble  statements  in  a  program.  This  is  based  on  observed  occurrences  of  opera¬ 
tors  and  operands. 
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The  Estimated  Length  (N)  is  a  metric  used  to  predict  the  ideal  length  of 
an  implementation  based  only  on  the  number  of  unique  operators  and  operands 
available  in  the  language  used.  This  metric  is  often  compared  with  the 
observed  length  to  determine  whether  impurities  are  present  in  the  implementa¬ 
tion.  Impurities  generally  reflect  poor  programming  practice  and  make  the 
implementation  less  concise  than  ideal. 

The  Volume  (V)  represents  the  number  of  bits  necessary  to  encode  the  pro¬ 
gram  using  one  character  per  operator  or  operand. 

The  Potential  Volume  (V«)  is  the  most  compact  form  the  program  could  take, 
considering  it  as  a  built-in  function  with  a  list  of  input  and  output  argu¬ 
ments.  This  term  is  often  based  on  opinion,  rather  than  calculation. 

The  Level  (L)  is  a  ratio  between  the  Potential  Volume  and  the  actual  Vol¬ 
ume.  It  is  often  regarded  as  an  indicator  of  the  level  of  abstraction  of 
implementation.  ^ Since  the  Potential  Volume  is  an  ambiguous  quantity,  the 
Estimated  Level  (L)  is  often  used,  for  it  is  dependent  on  readily  observable 
quantities. 

The  Intelligence  Content  (I)  is  an  estimate  of  the  Potential  Volume.  It 
is  independent  of  the  language  used  and  is  expected  to  be  invariant  over  dif¬ 
ferent  implementations  of  the  program. 

The  Language  Level  (A)  measures  the  expressive  power  of  a  particular  lan¬ 
guage.  High  level  languages,  that  allow  alternatives  for  expression,  have 
language  levels  greater  than  those  of  assembly  language.  Halstead  measured  a 
variety  of  languages  and  computed  the  following:  English  prose  =  2.16;  PL/I  = 
1.53;  FORTRAN  =  1.14;  and  Assembly  =  .88.  The  Language  Level  is  often  esti¬ 
mated  (A)  to  avoid  using  the  questionable  Potential  Volume  term. 

The  Effort  measure  (E)  is  used  to  predict  total  programming  time  when 
divided  by  the  Stroud  Number  (number  of  elementary  mental  discriminations  per 
second  by  a  human) .  Halstead  also  provided  a  formula  for  estimating  Effort 
(E)  which  provides  an  alternative  form.  This  alternative  is  discussed  in  more 
detail  in  Section  3.1.1. 


2.2.4  Distinguishing  Metrics  by  Phase  and  Automation  Potential 


This  section  establishes  the  potential  for  automatically  measuring  the 
McCall  [McC  79] ,  McCabe,  and  Halstead  metrics  in  the  early  life-cycle  phases, 
using  a  design  tool  such  as  DARTS. 

McCall  broke  down  the  software  development  process  into  requirements, 
design,  and  implementation  phases  to  indicate  when  the  metrics  could  be 
applied.  Later  versions  of  the  Framework  [Boe  83a]  [Boe  83b]  divided  the 
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design  phase  further,  into  the  Top  Level  and  Detailed  design  subphases,  but 
did  not  reclassify  the  metrics.  This  life-cycle  phasing  is  more  appropriate 
for  this  discussion  because  the  subphases  mirror  the  breakdown  into  prelimi¬ 
nary  and  critical  design  reviews,  and  architectural  and  detailed  design  docu¬ 
ments,  as  discussed  in  Section  2.1,  providing  measurable  products  and  proc¬ 
esses. 

The  criterion  which  determines  whether  a  metric  is  applicable  to  a  phase 
or  subphase  is  that  the  information  required  for  its  evaluation  be  present  in 
the  software  product  for  that  phase  or  subphase. 

For  the  requirements  phase,  the  product  is  the  Software  Requirements  Spec¬ 
ification;  for  the  design  subphases,  the  Software  Architectural  Design  Docu¬ 
ment  and  the  Software  Detailed  Design  Document.  For  the  implementation  phase, 
the  product  is  the  source  code. 

For  the  design  phase,  similar  information  is  contained  in  the  documents 
for  both  subphases,  but  the  level  of  detail  differs.  The  Proposed  Military 
Standard  on  Defense  System  Software  Development,  (MIL-STD-SDS)  [DoD  82] ,  out¬ 
lines  the  required  documents.  The  information  called  for  in  the  design  docu¬ 
ment  descriptions  includes  requirements  allocations,  interrupts,  timing  and 
sizing  estimates  and  budgets,  limitations  and  constraints,  special  require¬ 
ments,  interface  definitions,  database  definitions,  and  control  structure  and 
flow.  The  architectural  (Top  Level)  design  document  defines  these  items  for 
the  Computer  Software  Configuration  Item  (CSCI) ,  shows  the  structure  to  the 
Computer  Software  Component  (CSC)  level,  and  defines  the  required  items  for 
each  CSC. 

The  detailed  design*  document  evolves  from  the  architectural  design  docu¬ 
ment.  When  it  is  completed,  it  includes  a  full  breakdown  of  each  CSC  into 
units  and  modules,  to  the  level  required  for  coding.  All  the  control  logic  is 
shown,  and  the  data  structures  are  broken  down  to  individual  variables.  The 
items  listed  above  are  included  for  each  module.  (The  detailed  design  sub¬ 
phase  could  be  divided  in  two  to  yield  three  subphases  for  the  design  phase. 
The  first  part  of  detailed  design  would  have  a  product  in  which  the  breakdown 
into  units  and  modules  is  shown,  and  the  second  would  have  a  product  in  which 
the  logic  and  data  internal  to  each  module  is  shown.  The  former  would  show 
the  control  structure  for  the  whole  CSCI,  while  the  latter  would  provide  the 
code-to  specification  in  a  form  easy  to  parcel  out.) 

Whether  or  not  a  metric  can  be  measured  by  a  design  representation  tool 
depends  not  only  on  the  information  needed  to  evaluate  it  being  present,  but 
also  on  its  being  present  in  a  form  which  can  be  recognized  and  manipulated  by 
a  program.  Generally,  this  involves  providing  a  syntactically  recognizable 
form  for  the  information.  For  example,  in  DARTS,  the  input  and  output  data 
items  for  a  node  are  specified  separately  from  the  processing  description,  the 
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inputs  are  distinguished  from  the  outputs,  and  each  item  is  distinct.  This 
structure  makes  its  possible  to  answer  questions  like: 

1.  Are  any  data  items  specified  for  a  particular  node? 

2.  How  many  data  items  does  the  node  have? 

3.  How  many  input  items  does  the  node  have? 

4.  How  many  of  the  input  items  are  also  output  items? 

This  does  not,  however,  allow  us  to  answer  the  question, 

5.  Are  all  input  items  used  in  the  node? 

since  the  answer  depends  on  other  information  about  data  use  being  present  in 
the  database  and  in  a  form  that  can  be  processed.  As  an  alternative,  it  would 
have  been  possible  to  have  provided  a  field  for  data  items  where  input  and 
output  were  not  differentiated.  The  user  might  have  included  comments  distin¬ 
guishing  input  and  output.  The  information  content  of  the  database  would  be 
the  same,  but  the  capability  for  automatically  answering  the  questions  would 
not:  Questions  1  and  2  could  be  answered,  but  not  3-5.  Finally,  it  would 
have  been  possible  to  have  provided  no  separate  data  item  field.  The  user 
might  then  have  included  the  data  item  information  in  a  free  form  text  field 
associated  with  the  node.  Again,  the  information  content  would  be  the  same, 
but  in  this  case  none  of  the  questions  could  be  answered  automatically. 

Even  when  the  necessary  information  is  present,  some  metrics  are  inherent¬ 
ly  not  measurable  by  a  design  representation  tool,  because  they  involve  a 
knowledge  of  the  problem,  and  a  human  judgment  about  the  sufficiency  or  com¬ 
pleteness  of  the  design.  Most  of  the  McCall  metrics  are  really  checklist 
items,  such  as  making  sure  that  all  device  errors  are  handled  ( [McC  79] 
ET . 5 ( 2 ) ) ,  or  that  the  numerical  methods  used  are  sufficient  (AC.1(4)).  A  tool 
which  has  a  design  representation  as  its  database  cannot  tell  whether  some¬ 
thing  has  been  left  out  of  that  representation,  unless  it  can  do  so  by  check¬ 
ing  consistency  with  another  source  of  information  in  the  database.  It  could 
contain  a  list  of  such  items  and  let  the  user  check  them  off.  The  metrics 
could  be  derived  from  such  a  list. 

In  this  project,  DARTS  is  used  as  the  tool  context  in  which  the  metrics 
are  evaluated  for  potential  of  automatic  measurement.  The  context  for  infor¬ 
mation  content  is  based  on  the  design  documents  previously  mentioned. 
Although  most  of  the  information  called  for  in  the  design  documents  can  be 
included  in  a  DARTS  database,  much  of  it  can  be  expressed  only  as  comments  in 
the  free-form  text  associated  with  a  node.  Shown  in  Table  3  and  Table  4  is 
how  the  information  in  each  paragraph  of  the  MIL-STD-SDS  design  documents  can 
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be  represented  in  DARTS.  The  paragraph  numbers  are  taken  from  the  associated 
Data  Item  Descriptions  (DIDs)  ( [DoD  82]  R-DID-110  and  R-DID-111) . 

In  addition  to  the  presence  or  lack  of  information,  the  feasibility  of 
measuring  a  metric  automatically  depends  on  the  practicality  of  performing  the 
necessary  processing.  This  may  range  from  trivial  to  beyond  the  scope  of  the 
existing  technology. 

Table  3.  MIL-STD-SDS  Top  Level  Design  Document  Information  in  DARTS 


Paragraph  number 


Means  of  representation  in  DARTS 


3.1.1 

3.1.2 

3.2 

3.3.1 

3.3.2 

3.3.3 

3.3.4 

3.4 

3.4. X 

3.4. X.1 

3. 4. X. 2 

3.4. X. 3 

3. 4. X. 4 

3. 5.  all 

3. 6.  all 
4,  5,  7-9 
6 

10 


Text. 

Text. 

Text. 

Text. 

Text,  requirements  and  architectural 
design  trees. 

Architectural  design  tree,  data  set/use 
table,  module  table. 

Text  or  by  modelling  the  data  source 
as  a  data  producing  process. 

Text  or  by  modelling  the  data  source 
as  a  data  producing  process. 

Text. 

Text  or  could  be  modelled. 

Diagram,  ECSL  simulation  output. 

Diagram. 

DUR  statement  in  tab. 

Same  diagram  as  3.3. 

Text. 

Text. 

Indata,  Outdata;  data  set/use  table. 

Text. 

Text  or  by  modelling  a  handler. 

There  are  no  DARTS  facilities  naturally 
suited  for  representating  data  structures. 
Text. 

Intentionally  left  blank  in  DIDs. 

Text. 

Appendices  -  not  applicable. 


Paragraph  number 


Means  of  representation  in  DARTS 


1.1 
1.2 
2.  all 
3 

3.1 

3.1.1 

3. 1.1.1 

3. 1.1. 2 

3. 1.1. 3 

3. 1.1. 3. Y  a) 
3. 1.1. 3. Y  b) 
3. 1.1. 3. Y  C) 
3. 1.1. 3. Y  d) 
3. 1.1. 3. Y  e) 
3. 1.1. 3. Y  f) 
3. 1.1. 3. Y  g) 
3. 1.1. 3. Y  h) 
3. 1.1. 3. Y  i) 

3. 2.1. X. 6 

3. 2.1. X. 7 

3. 2.1. X. 8 

3. 2.1. X. 9 

3. 2.1. X. 10 

3. 2.1. X. 11 

3. 2.1. X. 12 

3.3 

4,  5,  7-9 
6 
10 


Text. 

Text. 

Text. 

Text. 

Database  printout. 

Diagram,  #variables. 

Text;  requirements,  architectural  design, 
and  detailed  design  trees. 

Text.  Timing  through  DUR  statements 
in  tabs,  output  of  ECSL  simulation. 
Diagram  except  data  structures. 

Data  descriptions  in  text. 

Text. 

Data  variables  -  partial. 

Diagram,  indata,  outdata. 
tvariables,  data  set/use  table. 

INV 

Diagram. 

Diagram. 

Data  set/use  table. 

Text. 

May  be  modelled. 

Text. 

DUR  statements  in  tabs. 

Text. 

Text. 

Diagram. 

May  be  modelled,  DUR  statements 
in  tabs. 

Text. 

Intentionally  left  blank  in  DIDs. 

Text. 

Appendices  -  not  applicable. 


2.2.5  Evaluation  of  Candidate  Metrics 

Table  5  summarizes  the  results  of  evaluating  each  of  the  metrics  in  [McC 
79]  Appendix  B,  the  McCabe  cyclomatic  complexity  metric  [McC  76] ,  and  the  var¬ 
ious  Halstead  metrics  [Hal  77] .  The  metrics  were  assessed  against  the  crite¬ 
ria  discussed  above  in  deciding  during  which  software  development  phase  they 
are  applicable,  and  whether  or  not  they  may  be  measured  by  using  the  informa¬ 
tion  in  a  DARTS  database. 

The  table  shows  [McC  79] ' s  designation  of  applicability  for  the  design 
phase  in  the  center  column  under  design  (labeled  McC) ,  between  the  desig¬ 
nations  for  the  architectural  (labeled  AD) ,  and  detailed  (labeled  DD)  design 
subphases.  When  the  designation  for  any  phase  disagrees  with  [McC  79] ,  it  is 
appended  with  an 

The  criteria  used  to  determine  each  metric's  potential  for  automation, 
noted  in  the  AUTO  column  of  the  table,  are  relative  to  the  current  implementa¬ 
tion  of  DARTS.  The  following  symbols  are  used  to  indicate  the  distinctions 
discussed  in  the  section  "Distinguishing  Metrics  by  Phase  and  Automation 
Potential." 

YO  -  Use  of  DARTS  guarantees  that  this  metric  takes  a  particular 
value.  For  example,  the  metric  MO. 2(1)  asks  how  much  of  the  design  is 
represented  in  a  hierarchical  structure.  DARTS  representations  are 
inherently  hierarchical,  so  the  metric  always  takes  the  value  1. 

Y1  -  The  information  needed  is  present  in  a  form  recognizable  by  a 
program,  so  the  metric  is  automatable. 

Nla  -  The  information  needed  is  not  present,  but  might  be  added. 

Nib  -  The  information  needed  is  not  present,  and  cannot  be  added. 

N1  -  The  information  needed  is  not  present,  and  is  not  really 
appropriate  in  a  design  representation  tool. 

Y2  -  The  information  needed  is  present,  but  not  in  a  recognizable 
form.  DARTS  could  be  changed  to  provide  a  syntactic  form  for  the  infor¬ 
mation. 

N2  -  The  information  needed  is  present,  but  not  in  a  recognizable 
form.  DARTS  cannot  be  changed  to  provide  a  syntactic  form  for  the  infor¬ 
mation. 

N3  -  The  information  needed  is  present,  but  the  metric  is  not  ame¬ 
nable  to  automatic  calculation.  It  asks  a  question  which  requires  under¬ 
standing  of  the  problem  being  expressed,  for  example,  whether  some  of  the 
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processing  expressed  in  the  design  is  complete,  sufficient,  or  correct; 
or  whether  a  particular  function  is  present  in  the  design. 

The  practicality  of  providing  the  necessary  processing  is  indicated  in  the 
table  in  a  gross  fashion.  An  is  appended  to  the  automatability  symbol  if 
the  processing  is  likely  to  involve  a  substantial  effort.  "Note"  follows  the 
table  entry  if  a  note  is  provided  in  the  following  section  to  comment  on  or 
explain  the  entry. 

2. 2. 5.1  Notes  on  Table  5 

CP. 1(1)  This  metric  asks  whether  or  not  all  references  are  unique,  e.g.,  a 
function  is  not  called  by  one  name  in  one  place  and  another  somewhere  else. 
This  is  really  a  completeness  question.  It  is  not  determinable  automatically, 
since  the  processing  will  assume  that  different  names  refer  to  different  enti¬ 
ties.  However,  the  data  set/use  table  and  the  module  table  present  the  infor¬ 
mation  needed  in  a  tabular  form  so  that  the  judgment  may  be  more  easily  made. 
For  example,  a  spelling  error  should  be  obvious. 

CP. 1(5)  This  metric  asks  whether  or  not  all  conditions  and  processing  are 
specified  for  each  decision  point.  This  could  be  enforced  if  DARTS  were  modi¬ 
fied  to  require  that  selector  nodes  have  n+1  offspring  for  n  predicates, 
instead  of  assuming  a  null  n+lst  offspring. 

CP. 1(8,9)  These  metrics  check  consistency  between  requirements  and  design, 
and  design  and  code.  [McC  79]  gave  this  up  as  too  difficult  to  measure. 

CS . 2 ( 2 )  This  metric  is  the  proportion  of  modules  which  do  not  conform  to 
naming  conventions.  Naming  conventions  should  be  used  from  the  beginning,  in 
requirements  definition,  to  help  traceability  and  prevent  confusion.  The 
"Nla"  index  here  is  used  to  indicate  that  a  particular  convention  could  be 
added;  the  "N3",  that  the  metric  relies  on  a  human  judgment. 

CS.2(3)  This  metric  calls  for  global  data  items  to  be  defined  in  the  same 
manner  in  all  modules,  so  it  is  another  example  of  measuring  conformity  to  a 
convention.  Insofar  as  global  items  may  be  defined  in  DARTS,  the  checknodes 
function  detects  anomalies. 


CS.2 (5)  This  metric  measures  data  type  consistency, 
implementation  language  would  enforce  this. 


A  strongly  typed 


ET.l(l)  This  metric  asks  whether  or  not  any  concurrent  processing  is  cen¬ 
trally  controlled.  Since  DARTS  provides  a  means  for  expressing  processing 
concurrency  and  data  exchange,  any  concurrent  design  expressed  in  it  will  be 
consistent.  The  metric  definition  does  not  contain  enough  detail  to  know  if 
this  is  what  is  meant,  or  if  it  is  a  checklist  item. 
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METRIC 

1 

1 

REOTS  | 

AD 

DESIGN 

McC 

DD 

IMPL 

|  AUTO  | 

1  1 

TR.  1 

Cross  reference  relating  modules 

1 

N  | 

Y 

Y 

Y 

Y 

1 . ! 

1  Nia  | 

to  requirements 

1 

i  i 

CP.  1 

COMPLETENESS  CHECKLIST 

1 

i  i 

(1) 

1 

7  1 

Y 

Y 

Y 

Y 

|  Y0/N3 | 

Note 

(2) 

1 

7  1 

Y 

Y 

Y 

Y 

1  Nia  | 

(3) 

1 

Y  | 

Y 

Y 

Y 

Y 

1  Y1  1 

(4) 

I 

7  1 

Y 

Y 

Y 

Y 

|  Y 1  | 

(5) 

1 

Y  1 

Y 

Y 

Y 

Y 

|  Y 1  | 

Note 

(6) 

1 

N  | 

N 

Y 

Y 

Y 

1  Nia  | 

(7) 

1 

7  1 

Y 

Y 

Y 

Y 

1  Nia  | 

(8) 

1 

N  | 

Y 

01 

Y 

N 

1  '  1 

Note 

(9) 

1 

N  | 

N 

D1 

N 

Y 

Note 

CS.  1 

PROCEDURE  CONSISTENCY  MEASURE 

1 

1  1 

(1) 

1 

N  | 

Y 

Y 

Y 

Y* 

1  YO  | 

(2) 

1 

N  | 

N 

Y 

Y 

Y 

1  vo  | 

(3) 

1 

N  | 

N 

Y 

Y 

Y 

1  N3  | 

(4) 

1 

N  | 

N 

Y 

Y 

Y 

1  N3  | 

CS.2 

DATA  CONSISTENCY  MEASURE 

1 

1  1 

(1) 

1 

N  ] 

N 

Y 

Y 

N* 

1  Nia  | 

(2) 

1 

Y*  | 

Y 

Y 

Y 

Y 

|  N1a/3 | 

Note 

(3) 

1 

N  | 

Y 

Y 

Y 

Y 

|  Nla/3 | 

Note 

(4) 

1 

N  | 

N 

Dt 

V 

Y 

(5) 

1 

N  | 

N 

D1 

Y 

Y 

Note 

AC.  1 

ACCURACY  CHECKLIST 

i 

1  1 

(1) 

1 

Y  ( 

N 

N 

N 

N 

(2) 

1 

Y  1 

N 

N 

N 

N 

1  *  1 

(3) 

1 

N  | 

N 

Y 

Y 

N 

1  N3  | 

(4) 

1 

N  | 

N 

Y 

Y 

Y 

1  N3  | 

(5) 

1 

N  | 

N 

N 

N 

Y 

1  *  1 

ET.  1 

ERROR  TOLERANCE  CTL  CHECKLIST 

1 

1  1 

(1) 

1 

N  | 

Y 

Y 

Y 

Y 

|  Y0/N3 | 

Note 

(2) 

1 

N  | 

N 

Y 

Y 

Y 

1  N3  | 

(3) 

t 

N  | 

N 

Y 

Y 

Y 

1  Nia  | 
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Table  5.  Metric  Applicability  and  Automatability  (Part  2  of  6) 


METRIC 

1 

1 

REOTS  | 

AO 

DESIGN 

McC 

DO 

IMPL 

AUTO 

1 

1 

1 

ET.2  RECOVERY  FROM  IMPROPER  INPUT 

(1) 

1 

1 

Y  | 

N 

N 

N 

N 

1 

1 

1 

(2) 

1 

N  | 

Y 

Y 

Y 

Y 

N3 

1 

(3) 

1 

N  | 

Y 

Y 

Y 

Y 

NO 

1 

(4) 

1 

N  | 

Y 

Y 

Y 

Y 

N3 

1 

(5) 

1 

N  | 

Y 

Y 

Y 

Y 

N3 

1 

ET.3  RECOVERY  FROM  COMP.  FAILURE 

(1) 

1 

1 

Y  | 

N 

N 

N 

N 

_ 

1 

1 

(2) 

1 

N  | 

N 

Y 

Y 

Y 

Nla* 

1 

Note 

(3) 

1 

N  | 

N 

Y 

Y 

Y 

Nla* 

1 

Note 

(4) 

1 

N  | 

N 

Y 

Y 

Y 

N3 

1 

ET.4  RECOVERY  FROM  HARDWARE  FAULTS 

(1) 

1 

I 

Y  | 

N 

N 

N 

N 

„ 

1 

1 

(2) 

1 

N  | 

Y 

Y 

Y 

Y 

N3 

1 

ET.5  RECOVERY  FROM  OEVICE  ERRORS 

(1) 

1 

1 

Y  | 

N 

N 

N 

N 

1 

1 

(2) 

1 

N  | 

Y 

Y 

Y 

V 

N3 

1 

SI.1  DESIGN  STRUCTURE  MEASURE 

(1) 

! 

1 

Y*  ) 

Y 

Y 

Y 

Y 

YO 

1 

1 

(2) 

1 

N*  1 

N 

N 

Y 

Y* 

N3 

1 

(3) 

1 

N*  | 

N 

N 

Y 

Y 

N3/Y2* 

1 

Note 

(4) 

1 

N*  | 

Y* 

N 

Y* 

Y 

N3 

1 

(5) 

1 

N  | 

N 

N 

Y* 

Y 

YO 

1 

(6) 

1 

N  | 

N 

Y 

Y 

Y 

YO/NIa | 

Note 

(7) 

1 

N  | 

N 

Y 

Y 

Y 

Nla 

1 

Note 

(8) 

1 

N  | 

Y 

01 

Y 

01 

- 

1 

(9) 

1 

N  | 

Y* 

N 

Y* 

D2 

- 

1 

SI. 2  USE  OF  STRUCTURED  LANGUAGE  OR 

1 

N  | 

N 

N 

N 

02 

• 

1 

Note 

PREPROCESSOR 

SI. 3  COMPLEXITY  MEASURE 

1 

1 

N  | 

Y 

Y 

Y 

Y 

Y2 

1 

1 

Note 

SI. 4  MEASURE  OF  COOING  SIMPLICITY 

(1) 

1 

1 

N  | 

N 

N 

N 

Y 

1 

1 

(2) 

1 

N  | 

N 

N 

N 

Y 

1 

(3) 

1 

N  | 

N 

N 

N 

Y 

1 

(4) 

1 

N  | 

N 

N 

N 

Y 

1 

(5) 

1 

N  | 

N 

N 

N 

Y 

1 

(S) 

1 

N  | 

N 

N 

N 

Y 

1 

(7) 

1 

N  | 

N 

N 

N 

Y 

1 

(8) 

1 

N  | 

N 

N 

N 

Y 

1 

(9) 

1 

N  | 

N 

N 

N 

Y 

1 

(10) 

1 

N  | 

N 

N 

Y  * 

Y 

Y  1 

1 

(ID 

1 

N  | 

N 

N 

Y* 

Y 

Y2 

1 

(12) 

1 

N  | 

N 

N 

N 

03 

- 

1 

(13) 

1 

N  | 

N 

N 

N 

01 

- 

1 

(  14) 

I 

N  | 

N 

N 

N 

02 

- 

1 

(15) 

1 

N  | 

N 

N 

N 

02 

- 

1 

(  IS) 

1 

N  | 

N 

N 

N 

01 

- 

1 
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Table  5-  Metric  Applicability  and  Automatability  (Part  3  of  6) 


METRIC  | 

! 

_  .  _  _  _  -  1 

REOTS  | 

AD 

DESIGN 

McC 

DO 

1 

1 

IMPL 

|  AUTO 

MO  .  1 

. . 1 

STABILITY  MEASURE  -  applicable  | 

D1  - 

.... 

... 

MO. 2 

MODULAR  IMPLEMENTATION  MEASURE  | 

1 

(D  1 

N  | 

Y 

Y 

Y 

1 

Y 

|  YO 

(2)  | 

N  | 

N 

N 

N 

1 

Y 

|  - 

(3)  | 

N  | 

N 

Y 

Y 

1 

Y 

|  Nla 

(4)  | 

N  | 

Y 

Y 

Y 

1 

Y 

1  Y1 

(5)  | 

N  | 

Y 

Y 

Y 

1 

Y 

1  Y1 

(6)  | 

N  | 

Y 

Y 

Y 

1 

Y 

|  YO 

(7)  1 

N  | 

N 

Y 

Y 

1 

Y 

|  N3 

(8)  | 

N  | 

Y 

D1 

Y 

1 

D 1 

|  N3 

GE.1 

EXTENT  TO  WHICH  MODULE  IS  | 

1 

1 

1 

REFERENCED  BY  OTHER  MODULES  | 

N  | 

Y 

Y 

Y 

1 

Y 

1  Y1 

GE.2 

IMPLEMENTATION  FOR  GENERALITY  | 

1 

(D  1 

N  | 

N 

Y 

Y 

1 

Y 

|  N3 

(2)  | 

N  | 

N 

Y 

Y 

1 

Y 

|  N3 

(3)  1 

N  | 

Y 

Y 

Y 

1 

Y 

|  N3 

(4)  | 

N  | 

Y 

Y 

Y 

1 

Y 

|  N3 

(5)  1 
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1 

Y 
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1 

(D  1 

N  | 

Y 

Y 

Y 

1 

Y 

|  N1 
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N  | 
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Y 

Y 

1 

Y 

|  N 1 
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Table  5.  Metric  Applicability  and  Automatability .  (Part  6  of  6) 


METRIC 
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1  ? 

1 

HALSTEAD'S  METRICS 

1  1 

1 
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Y 
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1 
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1 
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ET. 3(2,3)  These  metrics  ask  whether  or  not  all  loop  ana  multiple  transfer 
index  parameters  and  subscripts  are  range  checked  before  use.  A  higher  level 
implementation  language  may  have  these  capabilities. 

SI. 1(3)  This  metric  asks  whether  or  not  module  processing  is  dependent  on 
prior  processing.  Evaluation  of  it  depends  on  understanding  the  content  of 
the  module,  hence  the  "N3".  The  "Y2*n  is  to  indicate  that  reuse  of  local  var¬ 
iables  could  be  checked  by  interpreting  tab  statements,  but  is  a  difficult 
job.  Though  the  no  memory  principle  is  usually  a  good  one  to  follow,  there 
are  cases,  like  state  machines  and  filters,  where  it  is  not  the  method  of 
choice. 

SI. 1(6, 7)  These  metrics  have  to  do  with  database  characteristics.  DARTS 
could  be  modified  to  support  them  by  addition  of  data  structures.  The  number 
of  variables  could  be  used  for  (6),  the  size  of  the  database. 

51. 2  This  metric  asks  whether  or  not  a  structured  language  or  preprocessor 
is  used.  As  described,  it  is  for  the  implementation  phase.  An  analog  could 
be  developed  for  the  design  subphases. 

51. 3  This  metric  measures  data  and  control  flow  complexity.  It  depends  on 
the  feasibility  of  deriving  a  graph  representation  from  the  DARTS  database. 

SI. 4(1-4, 6)  These  metrics  measure  coding  simplicity  using  various  methods. 
Analogs  could  be  developed  for  the  design  subphases. 

EX. 2 (3)  This  metric  is  the  percent  of  speed  capacity  uncommitted.  Though 
[McC  79]  show  its  application  during  implementation,  it  should  be  included  in 
the  design  phase,  since  tight  machine  resources  have  a  dramatic  effect  on 
design. 

SD.l  This  metric  measures  the  quantity  of  comments.  An  analog  could  be 
developed  for  the  design  subphases. 

SD.2  This  metric  measures  the  effectiveness  of  comments.  An  analog  could 
be  developed  for  the  design  subphases. 

SD.3  This  metric  measures  the  descriptiveness  of  the  implementation  lan¬ 
guage.  An  analog  could  be  developed  for  the  design  subphases. 

EE.l  This  metric  asks  whether  or  not  the  performance  requirements  are 
allocated  to  the  design.  If  a  document  existed  which  tagged  each  requirement 
(say  by  paragraph  number) ,  the  tags  could  be  included  in  the  requirement  and 
design  diagrams.  A  metric  could  then  be  devised,  but  it  would  have  the  prob¬ 
lem  of  quantifying  completeness,  since  the  requirements  to  des- allocation 
may  be  many-to-one,  one-to-one,  or  one-to-many. 
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EE.2 (1)  This  metric  asks  what  proportion  of  non-loop-dependent  computa¬ 
tions  are  in  loops.  Some  higher  level  language  optimizing  compilers  will  min¬ 
imize  this.  There  may  be  practical  exceptions  to  this  principle. 

EE.2 (8)  This  metric  asks  whether  or  not  the  storage  facility  is  used  effi¬ 
ciently.  The  definition  given  is  too  vague  for  an  evaluation  to  be  made, 
depending  on  "evaluation  of  the  utility  of  the  storage  facility".  Also,  the 
table  shows  this  in  the  design  phase,  but  not  in  implementation,  which  is 
probably  a  mistake. 

EE. 3(2, 3, 4)  These  are  data  usage  efficiency  measures  for  the  implementa¬ 
tion.  Analogs  could  be  developed  for  the  detailed  design  subphase.  A  higher 
level  language  with  strong  typing  might  detect/prohibit  mixed  mode 
expressions. 

EE. 3 (5)  This  definition  is  not  detailed  enough  for  an  evaluation  to  be 
made . 

EE. 3 (6, 7)  These  metrics  ask  about  the  numbers  of  static  and  dynamic  data 
items.  They  may  be  applicable  to  the  detailed  design  subphase,  as  well  as 
implementation.  The  variables  could  be  partitioned  into  those  which  are 
changed  and  those  which  are  not,  by  interpreting  the  tab  statements.  The  met¬ 
ric  might  be  more  suitably  measured  in  a  tool  based  on  a  compiler,  since  a 
compiler  typically  processes  this  kind  of  semantic  information.  It  might  be 
suitable  for  a  PDL-like  design  tool. 

SE.l  This  metric  is  concerned  with  storage  efficiency.  It  depends  on  a 
variable  having  a  locus  of  definition,  which  might  or  might  not  be  true  in  a 
design  representation.  If  it  is,  the  information  necessary  is  present,  but 
the  metric  requires  knowledge  of  the  meaning  of  the  variables,  and  so,  is  not 
automatable . 

AC.l  and  AA.l  are  further  examples  where  the  metric  registers  whether  or 
not  a  particular  functional  cabability  is  present  in  the  system. 

OP. 1(5),  TN . 1 ( 1 , 2 )  These  metrics  deal  with  job  set  up  and  tear  down  proce¬ 
dures,  and  training  material.  Some  of  the  specification  called  for  in  these 
two  categories  should  start  during  design,  so  that  user  feedback  may  be 
obtained  to  influence  design. 

MI. 1(1)  This  metric  measures  machine  independence  in  terms  of  whether  the 
programming  language  used  is  available  on  other  machines.  If  the  implementa¬ 
tion  language  is  chosen  early  in  the  lifecycle,  the  metric  could  be  measured 
during  the  design  phase. 
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MI. 1(2)  This  metric  has  to  do  with  limiting  the  number  of  I/O  references 
in  a  module.  "I/O  reference"  is  not  defined  specifically  enough  to  enable  an 
evaluation. 


2.2.6  Metric  Automation  Potential  Summary 

The  totals  for  each  category  used  in  assessing  automation  potential  are 
shown  in  Table  6  for  the  McCall  metrics.  The  McCabe  and  Halstead  metrics  are 
considered  separately,  below.  (At  of  roughly  100  McCall  metric  components, 
about  25%  (29)  are  good  prospects  for  measuring  in  DARTS  (the  Y0,  Yl,  Nla  and 
Y2  categories) . 

Table  6.  Automation  Summary  for  McCall  Metrics 


Category 

Total 

Y0 

5 

Yl 

8 

Nla 

14 

Nla* 

4 

Nib 

4 

N1 

8 

Y2 

2 

N2 

1 

• 

N3 

57 

There  are  a  number  of  metrics  which  have  as  their  values  the  proportion  of 
modules  which  conform  to  a  set  of  conventions:  naming,  standard  represen¬ 
tation  for  procedures,  data,  etc.  They  are  mostly  in  the  N3  category.  The 
conventions  themselves  are  left  unspecified,  since  different  ones  may  be  suit¬ 
able  for  different  projects.  A  design  tool  would  clearly  be  able  to  check  for 
adherence  to  a  particular  convention. 

Another  class  of  metrics  is  composed  of  what  are  really  checklist  items, 
like  making  sure  that  all  device  errors  are  handled.  They  make  up  the  largest 
part  of  the  N3  category.  The  metric  depends  on  an  assertion  by  a  person  that 
a  module  meets  a  certain  criterion.  This  checklist  capability  is  a  function 
separable  from  design  representation  and  metric  measurement.  We  should  con¬ 
sider  whether  a  tool,  or  part  of  a  unified  tool  package,  would  be  of  use  in 
this  area.  It  could  act  as  a  prompter  for  the  system  developers,  and  a  quali¬ 
ty  assurance  audit  tool.  The  metrics  in  this  class  could  be  measured  from  it. 
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A  few  other  metrics  have  the  purpose  of  promoting  conservative  code  prac¬ 
tice  assuming  that  the  final  code  will  be  in  assembler  language,  such  as  loop 
index  range  checking.  As  indicated  in  the  notes  for  the  table,  they  might  be 
unnecessary  if  a  high  level  language  were  used. 

The  McCabe  cyclomatic  complexity  metric  may  certainly  be  automated,  since 
the  DARTS  primitives  represent  the  structure  programming  control  structures. 

The  Halstead  metrics  may  all  be  automated,  since  they  all  depend  on  the 
basic  counts  of  operators  and  operands,  easily  captured  from  many  forms  of 
design  media. 

The  McCabe  and  Halstead  metrics  were  chosen  for  use  in  the  other  tasks  of 
the  project.  Many  of  the  McCall  metrics  have  some  components  which  are  suit¬ 
able  for  automation  in  DARTS,  and  some  which  are  not;  which  makes  them  of 
dubious  use  as  a  demonstration  of  automatic  measurement.  The  McCabe  and  Hal¬ 
stead  metrics  present  a  coherent  picture  of  the  complexity  of  the  software, 
which  is  one  of  the  McCall  metrics.  In  addition,  the  Halstead  metrics  have 
been  shown  to  be  of  some  use  in  predicting  planning  parameters. 


2.3  DESIGN  METRICS  AND  DARTS 


The  next  sections  present  the  software  requirements  and  design  for  the 
McCabe  and  Halstead  metric  implementation  in^  the  CSDL  design-aid  tool  DARTS. 


2.3.1  McCabe's  Cyclomatic  Complexity  Metric 


This  section  includes  the  requirements  and  detailed  design  specification 
for  the  implementation  of  McCabe's  cyclomatic  complexity  metric  [McC  76]  in 
DARTS . 

2. 3. 1.1  Requirements 


The  McCabe  cyclomatic  complexity  metric  shall  be  implemented  in  DARTS. 
The  McCabe  module  shall  be  in  PL/I,  fit  into  the  existing  software  structure, 
use  the  existing  database  access  routines,  and  use  other  existing  utility  rou¬ 
tines  where  feasible.  The  user  shall  specify  the  top  node  and  depth  of  the 
subtree  to  be  measured.  The  output  shall  show  which  subtree  was  analyzed,  and 
include  the  metric  values  for  each  distinct  module  and  the  total  for  the  spec¬ 
ified  subtree. 
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advantageous  to  hide  some  details  of  a  design  to  show  only  the  higher  levels. 
Truncation  often  leaves  ambiguous  iterator  and  selector  nodes  (decision  nodes 
with  no  offspring).  In  these  cases,  if  the  tab  for  the  iterator  or  selector 
has  predicates  in  it,  processing  shall  be  as  normal.  If  the  tab  has  no  predi¬ 
cates,  an  iterator  shall  be  assumed  to  have  a  single  simple  predicate  to  ter¬ 
minate  the  loop.  A  selector  shall  be  assumed  to  have  a  single  simple 
predicate  used  to  distinguish  between  two  offspring  (an  IF-THEN-ELSE) . 

2. 3. 1.2  The  DARTS  Implementation  of  McCabe's  Metric 

Cyclomatic  complexity  may  be  measured  from  a  DARTS  representation  of  a 
design,  since  the  DARTS  primitives  represent  control  flow.  The  definition 
based  on  counting  the  binary  predicates  is  the  most  natural  one  to  implement, 
since  the  non-real-time  control  structures  in  DARTS  are  the  same  as  those  used 
frr  structured  programming. 

The  following  figures  show  the  DARTS  tree  representations  of  the  common 
control  structure  primitives  and  explain  their  graph  equivalents.  The  trees 
for  component  and  exchange  nodes  are  not  shown  since  they  are  just  single 
nodes:  they  do  not  represent  any  control  structure. 

The  coordinator  (Figure  2)  represents  parallel  execution  of  two  or  more 
processes,  so  the  equivalent  graph  would  include  each  process  as  a  separate 
unconnected  component.  As  discussed  below,  the  graph  medium  does  not  allow 
representation  of  control  interactions  brought  about  by  timing  relations  and 
data  exchanges,  so  coordinators  will  be  treated  as  sequencers  for  this  meas¬ 
urement. 

The  DARTS  iterator  (Figure  3)  can  be  used  to  represent  any  kind  of  loop, 
including  FOR,  WHILE,  or  UNTIL  loops.  It  may  have  one  of  two  graph  equiv¬ 
alents  depending  on  whether  the  loop  termination  test  occurs  at  the  beginning 
or  end  of  the  loop.  Any  number  of  steps  may  occur  inside  the  loop. 

The  selector  (Figure  4)  is  used  to  select  one  from  a  group  of  alterna¬ 
tives.  It  may  represent  an  IF,  IF-THEN-ELSE,  or  CASE  construct.  If  n-1  pred¬ 
icates  are  specified,  an  nth  selection  may  be  chosen  if  they  are  all  false; 
but  there  need  not  be  an  nth  selection.  Its  graph  would  include  a  multi-way 
branch  or  a  series  of  nested  binary  branches. 

The  sequencer  (Figure  5)  just  ties  together  nodes  which  are  executed  one 
after  the  other.  It .  graph  equivalent  is  linear.  Any  number  of  steps  may 
occur  in  sequence. 
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The  rest  of  this  section  details  how  the  metric  is  implemented  in  DARTS, 
ensuring  that  the  criteria  are  met  for  application  of  the  simplified  defi¬ 
nition  based  on  counting  decisions.  That  is,  that  the  control  graph  for  the 
DARTS  tree  is  connected,  planar,  and  has  a  single  entry  and  exit.  Points  con¬ 
sidered  are: 

1.  the  applicability  of  the  metric  to  multi-process  systems,  and  systems 
using  the  real-time  data  exchange  construct, 

2.  the  influence  on  the  metric  of  the  statements  of  the  tab  language, 

3.  how  the  number  of  modules  in  a  system  will  be  determined, 

4.  and  how  predicates  will  be  counted  for  each  type  of  DARTS  node. 

The  cyclomatic  complexity  metric  is  not  intended  to  measure  complexity  due 
to  real-time  aspects  of  a  problem.  Another  metric  must  be  used  to  cover  this 
area.  The  real-time  constructs,  coordinator  and  exchange  nodes,  may  have 
predicates  implied  in  their  implementation,  just  as  the  implementation  of 
sequential  control  may;  but  to  the  designer,  they  are  primitives.  Exchange 
nodes  are  treated  as  component  nodes  and  coordinator  nodes  are  treated  as 
sequencer  nodes.  Since  the  complexity  due  to  timing  requirements  is  not 
reflected  in  this. metric,  this  is  a  reasonable  approximation.  See  the  dis¬ 
cussion  of  BLK  and  SEG  statements,  below,  for  causing  the  processes  under  a 
coordinator  to  be  handled  as  separate  modules. 

The  general  scheme  for  measuring  cyclomatic  complexity  is  to  traverse  a 
user-specified  subtree,  accumulating  the  number  of  decisions  and  simple  predi¬ 
cates  for  each  node.  The  number  of  decisions  plus  one  yields  the  lower  bound 
for  the  interval  described  by  Myers,  and  the  number  of  simple  predicates  plus 
one  gives  the  upper  bound.  The  value  of  the  metric  for  each  module  encount¬ 
ered  is  printed,  as  well  as  the  total  for  the  subtree  specified. 

A  software  design  in  DARTS  can  be  either  abstract  or  detailed.  The  level 
of  detail  is  represented  by  using  both  uninterpreted  and  interpreted  node 
forms.  Uninterpreted  nodes  are  those  which  do  not  contain  any  primitive  oper¬ 
ators  such  as  arithmetical  or  logical  operators  in  a  special  tab  area  beneath 
the  node  (see  example  DARTS  trees  in  the  Appendices).  Generally,  nodes 
appearing  near  the  root  node  of  a  process  architecture  tree  are  more  likely  to 
represent  uninterpreted  functions.  Interpreted  nodes  are  those  which  contain 
primitives  such  as  arithmetic  or  logical  operators  in  the  tab  area.  These  tab 
statements  are  used  to  indicate  actions  which  occur  at  the  node,  conditions 
under  which  control  transfers  are  made,  or  to  further  define  the  node. 

The  absence  or  presence  of  these  tab  statements  makes  a  significant  dif¬ 
ference  in  calculating  the  McCabe  metric  values,  so,  two  methods  are  used. 
For  nodes  without  tab  statements,  the  entire  user-specified  subtree  is  consid- 
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ered  as  one  module,  and  the  type  of  node  and  number  of  offspring  determine  the 
number  of  decisions  and  predicates.  This  method  is  useful  for  high-level 
designs,  where  the  simple  predicates  in  terms  of  actual  variables  and  the 
software  structure  in  terms  of  modules  are  often  not  known.  For  nodes  with 
tab  statements,  the  statements  are  inspected  and  used  to  determine  the  number 
of  modules  and  the  number  of  predicates.  Details  on  the  recognition  of  mod¬ 
ules  and  the  counting  of  predicates  follow. 

Modules  in  DARTS  are  indicated  by  two  statements  in  tabs:  BLK  and  SEG. 
Each  statement  assigns  a  name  to  a  subtree.  The  SEG  statement  defines  the 
subtree  as  a  subroutine  which  may  be  invoked  by  an  INV  statement  in  a  tab  in 
another  part  of  the  system  tree.  (Without  SEGs,  commonly  used  subtrees  must 
be  repeated  at  each  point  of  use) . 

When  a  BLK  or  SEG  statement  is  present  as  the  first  statement  in  the  tab, 
the  subtree  for  that  node  is  recognized  as  a  module,  and  a  separate  count  of 
decisions  and  predicates  is  made  for  it.  Its  metric  value  interval  is  shown 
separately  in  the  output.  Since  a  coordinator  node  is  handled  as  if  it  were  a 
sequencer,  the  processes  under  it  must  have  BLK  or  SEG  statements  in  their 
tabs  if  the  processes  are  to  be  handled  as  separate  modules. 

A  list  of  the  modules  invoked  is  compiled,  and  an  output  line  referencing 
a  footnote  is  output  if  the  corresponding  SEG  is  not  present  in  the  specified 
subtree.  In  this  case,  the  totals  shown  for  the  user-specified-  subtree  are 
incorrect,  since  the  values  for  the  missing  SEGs  are  not  included. 

In  the  following  specification  for  how  the  numbers  of  decisions  and  predi¬ 
cates  are  determined,  "simple  predicate"  is  used  to  indicate  what  McCabe  calls 
a  predicate,  and  "tab  predicate"  is  used  for  a  DARTS  tab  predicate,  which  may 
actually  be  a  conjunction  of  several  simple  predicates. 

For  nodes  without  tab  statements,  each  iterator  node  is  assumed  to  have  a 
single  decision  to  terminate  the  loop.  Each  selector  node  is  assumed  to  have 
a  decision  to  reach  each  of  its  offspring  except  the  last  (the  ELSE  branch), 
so  the  number  of  decisions  is  the  number  of  offspring  minus  one.  If  there  are 
no  offspring,  the  selector  is  assumed  to  have  a  single  decision  used  to  dis¬ 
tinguish  between  two  offspring  (an  IF-THEN-ELSE) .  All  other  node  types  have 
zero  decisions.  For  all  node  types,  the  number  of  predicates  is  the  same  as 
the  number  of  decisions. 

For  nodes  with  tab  statements,  all  node  types  except  iterators  and  selec¬ 
tors  again  have  zero  decisions  and  zero  predicates. 

Iterator  nodes  may  or  may  not  have  a  tab  predicate  specified  in  the  tab 
text.  Those  with  no  tab  predicate  will  be  assumed  to  have  a  single  unstated 
decision/predicate  for  terminating  the  loop,  as  for  nodes  without  tab  state¬ 
ments.  For  those  with  a  tab  predicate,  the  number  of  decisions  is  still  one, 
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but  the  number  of  simple  predicates  is  the  number  of  ANDs  in  the  first  tab 
predicate  plus  one.  (The  number  of  ANDs  is  one  less  than  the  number  of  simple 
predicates  which  they  join;  and  ORs  are  not  allowed).  Since  iterators  are 
used  to  represent  a  number  of  different  kinds  of  loops,  including  FORs,  WHILES 
and  UNTILs,  this  method  corresponds  to  mechanizing  any  kind  of  loop  as  a 
series  of  nested  IF-THEN-ELSEs. 

Selector  nodes  also  may  or  may  not  have  tab  predicates  specified  in  the 
tab  statements.  They  are  used  to  represent  constructs  such  as  IF-THEN-ELSE 
and  CASE,  so  more  than  one  tab  predicate  may  be  present.  Those  with  no  tab 
predicate  will  be  treated  as  if  there  were  no  tab  statements.  For  those  with 
tab  predicates,  the  number  of  decisions  is  the  same  as  for  selectors  without 
tab  statements.  The  number  of  simple  predicates  in  each  tab  predicate  is 
determined  as  it  is  for  iterators,  and  the  sum  for  all  the  tab  predicates  is 
the  number  of  simple  predicates  for  the  node.  Again,  this  reflects  the  mecha¬ 
nization  of  any  selector  as  a  series  of  nested  IF-THEN-ELSEs. 

A  tab  statement  is  recognized  as  a  predicate  according  to  the  specifica¬ 
tions  in  [CSDL82] .  That  is,  if  the  statement  does  not  begin  with  one  of  the 
reserved  words  ( BLK ,  SEG,  etc.),  and  it  contains  one  of  the  relational  opera¬ 
tors  EQ,  NE,  GT,  GE,  LT,  or  LE.  The  tab  statement  TRUE  is  also  recognized  as 
a  predicate.  Redundant  or  degenerate  simple  predicates,  such  as  "X  GT  3  AND  X 
GT  3"  or  "TRUE  AND  X  GT  3"  are  not  detected.  Handling  of  variable  names  which 
are  reserved  words  is  undefined. 


2.3.2  Halstead's  Software  Science  Metrics 

This  section  specifies  how  the  Halstead  counting  method,  and  the  associ¬ 
ated  metric  calculations  are  implemented  in  DARTS  to  assess  the  quality  of 
software  designs.  It  is  expected  that  this  metric  analysis  will  provide 
designers  and  managers  with  useful  feedback  during  software  development. 

2. 3. 2.1  Requirements 

The  Halstead  parameters  shown  in  Table  2  shall  be  measured  in  DARTS. 
Operators  and  operands  shall  be  identified  in  the  DARTS  medium  and  a  counting 
method  shall  be  defined  which  is  consistent  with  the  definitions  provided  in 
by  Halstead  [Hal  77].  The  Halstead  module  shall  be  written  in  PL/I,  fit  into 
the  existing  DARTS  software  structure,  use  the  existing  database  access  rou¬ 
tines,  and  use  other  existing  utility  routines  where  feasible.  The  user  shall 
specify  the  top  node  and  depth  of  the  subtree  for  which  the  parameters  are  to 
be  measured,  and  the  counting  method  to  be  used.  The  output  shall  show  which 
subtree  was  measured,  which  counting  method  was  used,  and  the  parameter  values 
for  the  specified  subtree. 
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2. 3. 2. 2  The  DARTS  Implementation  of  Halstead's  Metrics 

The  following  discussion  defines  the  identification  of  operators  and  oper¬ 
ands  and  a  method  for  counting  their  occurrences  in  a  software  design  repres¬ 
ented  as  a  DARTS  tree,  according  to  the  generalized  technique  developed  in 
Section  2. 2. 3. 2.  This  technique  evolved  from  prior  work  [Szu  80]  and  [Szu 
8l] .  The  DARTS  Halstead  Metric  capability  was  implemented  in  three  evolution¬ 
ary  forms.  Simple,  Uninterpreted,  and  Interpreted.  For  this  project,  only  the 
Interpreted  form  is  discussed. 

Since  a  software  design  in  DARTS  can  be  either  abstract  or  detailed,  the 
technique  used  to  identify  operators  and  operands  assumes  that  a  DARTS  tree 
has  both  uninterpreted  and  interpreted  node  forms.  Uninterpreted  nodes  are 
those  which  do  not  contain  any  primitive  operators  such  as  arithmetical  or 
logical  operators  in  the  tab.  Generally,  nodes  appearing  near  the  root  node 
of  a  process  architecture  tree  are  more  likely  to  represent  uninterpreted 
functions.  These  nodes  are  generally  identified  as  unique  operators  and  con¬ 
tribute  a  count  of  one  to  each  of  the  basic  operator  equations. 

Interpreted  nodes  are  those  which  contain  primitives  such  as  arithmetic  or 
logical  operators  in  the  tab  field.  Control  qualifiers  (e.g.,  if,  then,  else, 
etc.)  are  also  considered  primitives,  as  are  semicolons  used  for  punctuation. 
A  list  of  all  primitive  operators  which  are  interpreted  by  the  DARTS  Halstead 
module  is  shown  in  Table  7. 

Table  7.  DARTS  Software  Science  Operator  Primitives. 
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The  Halstead  operands  in  a  DARTS  design  are  those  data  items  appearing  in 
the  tab  field  which  are  not  operators.  The  Potential  Volume  (V*)  is  deter¬ 
mined  by  evaluating  n2*  as  the  number  of  data  items  on  the  INDATA  (input 
data) ,  and  OUTDATA  (output  data)  lists  of  the  top  node  of  the  tree  under  meas¬ 
urement. 
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2. 3. 2. 2.1  SPECIAL  PROCESSING:  DARTS  uses  a  hierarchical  representation  tech¬ 
nique  which  allows  a  user  to  truncate  trees  at  any  level.  This  is  useful  when 
it  is  advantageous  to  hide  some  details  of  a  design  to  show  only  the  higher 
levels.  Truncation  often  leaves  ambiguous  decision  nodes  (i.e.,  decision 
nodes  with  no  offspring).  When  this  occurs,  the  node  is  redefined  to  be  a 
unique  uninterpreted  functional  node. 


2.4  USING  THE  DARTS  DESIGN  METRICS 


Preceding  sections  of  this  report  have  identified  metrics  which  purport  to 
determine  the  quality  of  software  designs.  These  metrics  can,  at  this  time, 
be  used  as  comparators  between  functionally  equivalent  but  different  designs 
but  not  as  yardstick  measures  on  designs  in  isolation.  Several  articles  in 
the  literature  have  included  examples  of  good  programming  style  contrasted 
with  implementations  which  lack  proper  organization,  structure,  and  clarity. 
In  some  cases,  the  examples  already  contain  relevant  metric  data,  though  in 
general,  the  data  is  derived  manually  from  the  code.  This  section  is  an 
attempt  to  provide  some  empirical  data  to  support  the  utility  of  automated 
design-aids  and  metrics  by  applying  the  metrics  to  designs  encoded  in  the 
DARTS  database. 

In  the  two  sections  to  follow,  both  the  Halstead  and  McCabe  metrics,  as 
implemented  in  DARTS,  are  used  to  evaluate  some  simple  and  complex  designs 
which  are  encoded  in  the  DARTS  data-base. 


2.4.1  Simple  Examples 

In  this  section,  two  examples  have  been  taken  from  the  literature  [Ker 
74].  These  examples  are  part  of  the  CACM  collection,  "programming  style", 
containing  examples  and  counterexamples.  They  were  carefully  chosen  by  the 
authors  to  depict  obvious  differences  between  good  and  bad  code.  The  examples 
chosen  were  also  evaluated  by  the  Halstead  metric  in  an  article  by  Gordon  [Gor 
79].  The  results  of  DARTS  Halstead  analysis  and  Gordon's  are  compared.  In 
addition,  the  McCabe  Cyclomatic  Complexity  is  also  calculated. 

2. 4. 1.1  CACM  Example  14a 

This  simple  PL/I  billing  program  was  translated  into  a  DARTS  detailed 
design,  then  analyzed  by  the  DARTS  Halstead  and  McCabe  metrics.  The  DARTS 
representation  of  the  program  can  be  found  in  Section  B.l  of  Appendix  B. 
Figure  6  shows  the  PL/I  code  and  Gordon's  [Gor  79]  Halstead  metric  analysis. 
Table  8  shows  the  DARTS  Halstead  and  McCabe  metric  analysis  printout  tables 
for  comparison. 
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IF  QTY  >  10 

THEN  IF  QTY  >  200 

THEN  IF  QTY  >  =500 

THEN  BILL  A=BILL  A  +  1 .00; 
ELSE  BILL  A=BILL  A  +  0.50; 

ELSE; 

ELSE  BILL  A=0.00. 

The  code  of  Example  14A. 


Number 

14A 


*1 
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N1 

n2 
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1/L 
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8 
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21 

14 

140 

7.00 

980 

Figure  6.  PL/I  Code  and  Gordon's  Metric  Data  -  CACM  14a 


2. 4 -1.2  CACM  Example  14b 

This  simple  PL/I  billing  program  was  translated  into  a  DARTS  detailed 
design,  then  analyzed  by  the  DARTS  metrics.  The  DARTS  representation  of  the 
program  can  be  found  in  Section  B.2  of  Appendix  B.  Figure  7  shows  the  PL/I 
code  and  Gordon's  [Gor  79]  Halstead  metric  analysis.  Table  9  shows  the  DARTS 
Halstead  and  McCabe  metric  analysis  printout  tables  for  comparison. 
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Table  8.  DARTS  Halstead  and  McCabe  Analysis  -  CACM  14a 


CSOL  «•  DESIGN-AIDS 

TOPI  POE  10:3 

PAGE 

1 

FOR  REAL-TIME  SYSTEMS 

ALL  GENERATIONS 

DATE: 

OB  SEPT  1903 

HALSTEAD  ICTRZC 

COUNTZNB  METHOO:  INTERPRETED 

DATABASE  IS:  U5A 

USER  ZSt  AJR1392 

TIME: 

14:37:20 

TOTAL  OPERATORS 


POTENTIAL  VOLUME 


DESIGN  LEVEL 


ESTIMATED  DESIGN  LEVEL 


INTELLIGENCE  CONTENT 


LANBUA8S  LEVEL 


ESTIMATED  LANGUAGE  LEVEL 


El 


14 


16 


35 


40.0 


-37.14 


140.000 


4.755 


0.034 


0.143 


20.000 


0.161 


2.057 


4122.074 


ESTIMATED  EFFORT 

900.000 

CSOL  Ml  DESIGN- AIDS 

TOPIPDE  ID:S 

PAGE 

3 

FOR  REAL-TIME  SYSTEMS 

ALL  GENERATIONS 

DATE: 

23  AUG  1903 

MCCABE  METRIC 

DATABASE  IS:  T15A 

USSR  IS:  AJR1392 

TIME: 

13:40:20 

MCCABE  INTERVAL 

EDXCATES  LOCI  BOUND  UPPER  BOUND 
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>  ■>  --  •» 


>  >  v.*  v  V  V  .* 


IF  QTY  >  =500 

THEN  BILL  A=BILL  A  +  1.00; 

ELSE  IF  QTY  >200 

THEN  BILL  A=BILL  A  +  0.50; 
ELSE  IF  QTY  <=10 

THEN  BILL  A=0.00; 

The  code  of  Example  14B. 


Number  rjj  t72 

14B  9  8 


*1  N2  V 

19  14  135 


lit 

7.88  1062 


Figure  7.  PL/I  Code  and  Gordon’s  Metric  Data  -  CACM  14b 


-1.3  cars  RxaiKDlA  15a 


<w 


IF  X  >  =  Y 

THEN  IF  Y  >=Z; 

THEN  SMALL  =  Z; 
ELSE  SMALL  =  Y; 
ELSE  IF  X  >  =Z 

THEN  SMALL  =  Z; 
ELSE  SMALL  =  X; 

The  code  of  Example  1 5A 


Number 


10.50  1186 


Figure  8.  PL/ I  Code  and  Gordon's  Metric  Data  -  CACM  15a 


2. 4. 1.4  CACM  Example  15b 

This  simple  PL/I  program  was  translated  into  a  DARTS  detailed  design, 
then  analyzed  by  the  DARTS  metrics.  The  DARTS  representation  of  the  program 
can  be  found  in  Section  B.4  of  Appendix  B.  Figure  9  shows  the  PL/I  code  and 
Gordon's  [Gor  79]  Halstead  metric  analysis.  Table  11  shows  the  DARTS  Halstead 
and  McCabe  metric  analysis  printout  tables  for  comparison. 
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Table  10.  DARTS  Halstead  and  McCabe  Analysis  -  CACM  15a 


CSOL  «m  OESIGN-AXDS  TOPNOOE  10:2 

FOR  REA L'TW  SYSTEMS  ALL  GENERATIONS 

HALSTEAD  METRIC  DATABASE  ZSi  T1SA 

COUNTING  METHOD:  INTERPRETED  USER  ZSt  AJR1392 

PAGE 

DATE: 

TIME: 

1 

OB  SEPT  1983 
14:34:24 

OPERATORS 

COUNT 

OPERANDS 

COUNT 

If 

S 

X 

3 

GE 

Y 

3 

THEN 

Z 

4 

EG 

SMALL 

4 

1 

ELSE 

A 

20 

4 

14 

DISTINCT  OPERATORS 

4 

DISTINCT  OPCRAMS 

4 

TOTAL  OPERATORS 

20 

TOTAL  OPERANDS 

14 

VOCABULARY 

10 

DESIGN  LENGTH 

34 

ESTIMATED  LENGTH 

23.1 

PERCENT  OFF 

30. SB 

DESIGN  VQUJS 

112.944 

POTENTIAL  VOLUME 

2.000 

DESIGN  LEVEL 

o.oxa 

ESTIMATED  DESIGN  LEVEL 

O.OBS 

INTELLIGENCE  CONTENT 

10.7*7 

LANGUAGE  LEVEL 

O.OSS 

ESTIMATED  LANGUAGE  LEVEL 

1.02* 

EFFORT 

AS78.34B 

ESTIMATED  EFFORT 

110*.  028 

CSOL  «Nl  DESIGN-AIDS  TOPWOOE  10:2 

PAGE 

1 

FOR  REAL-TIME  SYSTEMS  ALL  GENERATIONS 

DATE: 

23  AUG  1983 

MCCABE  METRIC  DATABASE  IS: 

ns a 

TIME: 

13:40:01 

|  USER  XSi  AJR1392 

MCCAM  INTERVAL 

MODULI  NAM  OOCCXSXCNS  OOREDXCATIS  LOMR  BOUND  UPPER  BOUND 


IS  X  LARGER  TRAN  OR  EQUAL  TO  Y 

3 

3 

4 

4 

TOTAL  FOR  SUBSYSTEM 

IS  X  LARGER  THAN  OR  EQUAL  TO  Y 

3 

3 

4 

4 
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SMALL  =  X; 

IF  Y  <  SMALL 

THEN  SMALL  =  Y; 
IF  Z  <  SMALL 

THEN  SMALL  =  Z; 

The  code  of  Example  1 5B. 


Number 


tj2  Nj 


Figure  9.  PL/I  Code  and  Gordon's  Metric  Data  -  CACM  15b 


2. 4. 1.5  Analysis  of  the  Simple  Examples  Experiment 

The  subjective  evaluation  by  the  authors  of  the  programs  [Ker  74]  suggests 
that  Example  14a  is  better  than  Example  14b,  and  Example  15b  is  better  than 
Example  15a.  These  findings  were  reinforced  by  Gordon's  manual  application  of 
the  Halstead  metrics  [Gor  79] .  The  automated  DARTS  Halstead  analysis  of  these 
same  examples  reproduced  Gordon's  data,  and,  in  addition,  the  DARTS  McCabe 
metric  verified  the  results  in  one  of  the  two  cases.  In  the  case  of  Example 
14,  the  metric  values  were  the  same.  By  examining  the  control  structure  of 
these  programs,  it  is  obvious  that  the  McCabe  metric  cannot  distinguish 
between  these  two  similar  designs  at  the  level  of  detail  presented. 


In  this  section,  the  metrics  described  in  Section  2.3  are  applied  to  exam¬ 
ple  real-time  system  designs.  In  order  to  illustrate  the  ability  of  the  met¬ 
rics  to  distinguish  between  designs  of  differing  quality,  two  candidate  design 
solutions  to  a  complex  problem  are  introduced.  The  designs  are  expressed 
using  the  automated  design  medium  of  DARTS,  and  the  metrics  are  applied  auto¬ 
matically. 
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The  following  sections  introduce  the  sample  problem,  present  the  two  can¬ 
didate  designs,  and  apply  the  metrics  to  the  designs.  The  section  closes  with 
a  summary . 

2. 4. 2.1  The  Experiment  Controller  Example 

The  example  chosen  is  an  experiment  controller,  first  described  by  Men- 
delbaum  and  Madaule  [Men  75] ,  and  later  discussed  by  Chow  [Cho  78] .  The  com¬ 
puter  controls  a  series  of  laboratory  experiments,  positioning  a  burette 
piston  prior  to  each  experiment,  and  then  records  and  analyzes  sensor  data 
(e.g.,  determining  solute  concentration).  A  report  is  printed  at  the  end  of  a 
series  of  experiments;  however,  the  user  has  a  switch  which  causes  the  report 
to  be  issued  at  intermediate  points  if  desired.  The  detailed  requirements  for 
this  system  are  presented  in  Table  12,  and  Figure  10  is  a  pictorial  represen¬ 
tation  of  the  system. 

This  example  was  selected  for  a  variety  of  reasons. 

•  It  illustrates  a  number  of  real-time  design  issues,  including  asynchro¬ 
nous  user  interractioh ,  and  timer-driven  cyclic  behavior. 

•  There  are  two  designs  derived  from  the  same  requirements  which  can  be 
compared  both  subjectively  and  by  the  metrics. 

•  It  is  a  complex,  yet  simply  illustrated,  example. 

Each  design  is  depicted  using  DARTS.  Figure  11  shows  the  first  version  of 
the  design,  labeled  Design  1,  and  Figure  12  shows  the  second  version,  labeled 
Design  2.  The  DARTS  metric  analysis  of  these  designs  is  discussed  in  the  next 
section. 

2. 4. 2. 2  Metric  Analysis  of  the  Experiment  Controller  Designs 

In  this  section,  the  results  of  the  DARTS  Halstead  and  McCabe  metric  anal¬ 
ysis  of  the  Experiment  Controller  Example  designs  are  presented  and  discussed. 

Design  1,  as  depicted  in  Figure  11,  was  analyzed  using  DARTS.  Table  13 
shows  1)  the  raw  counts  of  operators  and  operands  used  to  calculate  the  Hal¬ 
stead  metrics,  2)  the  Halstead  metrics,  and  3)  the  McCabe  Cyclomatic  Complexi¬ 
ty  Interval. 

Design  2,  as  depicted  in  Figure  12,  was  also  analyzed  using  DARTS. 
Table  14  shows  1)  the  raw  counts  of  operators  and  operands  used  to  calculate 
the  Halstead  metrics,  2)  the  Halstead  metrics,  and  3)  the  McCabe  Cyclomatic 
Complexity  Interval. 
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Table  12.  Requirements  for  the  Experiment  Controller 


1.  A  computer  system  is  needed  to  control  a  series  of  laboratory  experiments  (see  Figure  4-1 ). 

2.  A  burette  step  motor  compresses  a  burette  piston.  Each  step  of  the  motor  corresponds 

to  a  given  poured  vt  iume.  Following  each  step  an  interrupt  signal  ig  is  sent  to  the  computer. 

3.  An  electric  cell  sensor  enables  the  computer  to  measure  concentrations  in  a  tank. 

4.  Experimental  data  are  sent  to  the  user  via  a  printer.  When  the  printer  has  finished  printing  a  list 

of  data,  an  interrupt  signal  ip  is  sent  to  the  computer. 

/■* 

5.  A  user  switch  enables  the  user  to  interrupt  and  obtain  a  status  report  during  the  experiments  by 
emitting  a  signal  iy. 

6.  The  computer  system  can  make  use  of  a  timer  to  request  an  interrupt  signal  ij  after  a  given  fixed 
interval. 

7.  Prior  to  performing  the  first  experiment,  an  INITIALIZATION  task  is  performed,  followed  by  an 
initial  reading  of  the  cell  sensor  and  the  MEASURE  task. 

8.  The  computer  has  access  to  a  count  of  the  number  of  experiments  and  an  experiment  table  con¬ 
taining  instructions  for  each  experiment  (the  initial  definition  of  this  table  is  not  part  of  the 
problem). 

9.  For  each  experiment,  the  burette  controller  motor  is  operated  for  a  number  of  steps  (as  determined 
from  the  experiment  table). 

10.  Next  a  series  of  measurements  is  performed  at  fixed  time  intervals  (as  determined  from  the  experi¬ 
ment  table),  by  starting  the  timer,  reading  the  sensor  when  the  timer  interrupt  occurs,  and  per¬ 
forming  the  MEASURE  task.  The  series  is  terminated  after  a  fixed  number  of  measurements  (as 
determined  from  the  experiment  table). 

11.  After  each  measurement,  if  the  user  has  sert  the  signal  iy,  the  COMPUTE  and  LIST  tasks  are  per¬ 
formed,  and  a  status  report  is  sent  to  the  printer. 

12.  After  each  experiment,  it  is  determined  whether  the  series  of  experiments  is  finished.  If  not, 
steps  9  through  1 1  above  are  repeated,  (f  so,  the  COMPUTE  and  LIST  tasks  are  performed,  and 
the  final  report  is  sent  to  the  printer. 

13.  The  report  cannot  be  sent  to  the  printer  if  the  printer  is  already  in  use  (it  is  delayed  until  the 
printer  is  available). 

14.  While  a  user  print  request  is  in  execution,  additional  user  print  requests  are  ignored. 
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Figure  10.  Experiment  Controller  System 


For  both  of  these  designs,  the  minimum  number  of  unique  operands  is  11. 
This  is  derived  from  counting  the  input  and  output  data  items  at  the  top  of 
each  design  tree.  This  information  is  obtained  from  the  data-flow  tables  for 
each  of  the  designs,  which  appear  in  Appendix  E.  As  Table  13  and  Table  14 
show,  the  important  complexity  metrics  of  Halstead’s  theory  (length,  volume, 
and  effort),  and  McCabe’s  Cyclomatic  Complexity  suggest  that  Design  1  is  less 
complex  than  Design  2.  This  agrees  with  a  subjective  assessment  that  a  profi¬ 
cient  designer  might  make  in  comparing  these  designs. 


2.5  DESIGN  METRICS  AND  ADA 


This  section  considers  how  Ada  may  be  used  as  a  dersign  representation 
medium  during  the  design  phase,  and  how  the  Halstead  metrics  may  be  measured 
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Figure  11.  Experiment  Controller  -  Design  1  (Part  3  of  3) 
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Figure  12*  Experiment  Controller  -  Design  2  (Part  1  of  5) 
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Table  14.  DARTS  Metrics  Summary  -  Design  2 
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from  such  a  design.  First,  to  what  extent  the  information  necessary  to  the 
products  of  the  design  phase  may  he  expressed  in  Ada  is  examined.  Then,  a 
counting  method  and  guidelines  for  measuring  the  Halstead  metrics  from  an  Ada 
design  are  proposed.  This  method  is  illustrated  with  am  example,  and  some  of 
the  issues  raised  are  discussed. 


2.5.1  Motivation 

As  Ada  compilers  and  Programming  Support  Env^  'onments  are  nearing  avail¬ 
ability  for  use  on  actual  projects,  there  is  much  interest  in  using  Ada, 
itself,  as  a  design  representation  medium.  This  is  appealing,  because  it  pro¬ 
vides  an  orderly,  evolutionary  way  to  progress  from  architectural  design 
through  detailed  design  to  full  implementation.  It  is  appropriate,  because 
the  language  provides  the  means  for  defining  objects  and  operations  which  are 
not  primitive  in  Ada,  through  type,  variable,  function,  procedure,  and  task 
declarations;  the  means  for  hiding  information  about  the  implementation  of  the 
objects  and  operations  through  packages  and  private  types;  and  the  means  for 
delaying  implementation  decisions  through  separate  compilation  of  package  spe¬ 
cifications  and  bodies.  Thus,  a  design  can  be  expressed  in  Ada  at  any  desired 
level  of  abstraction;  and  characteristics  such  as  interface  correctness  and 
data  typing  consistency  can  be  checked  through  use  of  the  compiler,  at  any 
stage  of  the  process. 

Objections  which  have  been  raised  to  using  Ada  as  a  design  representation 
medium  center  on  the  difficulty  of  restraining  designers  from  premature  intro¬ 
duction  of  implementation  detail,  and  the  need,  during  design,  for  information 
which  is  not  best  represented  in  Ada.  Subsets  and  supersets  of  Ada  have  been 
proposed  to  solve  these  problems. 


2.5.2  The  Object-Oriented  Design  Methodolc 


To  make  effective  use  of  Ada  as  the  design  representation  medium,  a  design 
method  must  be  employed  which  allows  easy  introduction  of  detail  as  design 
decisions  are  made,  but  discourages  the  premature  introduction  of  detail  which 
might  unduly  constrain  the  implementation,  one  such  method  is  the  object-or¬ 
iented  design  methodology  explicated  in  [boo  83] .  It  is  used  here  to  demon¬ 
strate  the  use  of  Ada  as  a  design  medium  and  is  summarized  in  the  following 
steps  ( [Boo  83]  p.  70) : 

1.  Define  the  problem. 

2.  Develop  an  informal  strategy  for  solving  the  problem.  State  the  prob¬ 
lem  solution  in  English. 

3.  Formalize  the  strategy  by 
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a.  Identifying  the  objects  used  in  the  solution,  and  their  attributes 


b.  Identifying  the  operations  which  are  performed  on  the  objects  dur 
ing  the  solution. 


c.  Establishing  the  interfaces  among  the  object-operation  groups. 


d.  Implementing  the  objects  and  operations. 


This  last  step  defines  a  new  problem,  so  all  the  steps  may  be  repeated  at  sue 
cessively  greater  levels  of  detail,  until  a  code-to  design  is  reached. 


This  method  is  also  consistent  with  expression  of  the  design  using  DARTS 
since  DARTS  supports  hierarchical  decomposition. 


2.5.3  Using  Ada  as  a  PDL  with  the  Object-Oriented  Design  Method 


Ada's  information  hiding,  data  abstraction,  acid  strong  typing  capabilities 
make  it  very  suitable  for  expressing  a  design  which  is  developed  according  to 
the  object-oriented  design  methodology,  or  another  top-down,  stepwise  refine¬ 
ment  method.  The  objects  become  constants  or  variables  of  appropriate 
user-defined  data  types,  or  tasks;  the  operations  become  procedures,  func¬ 
tions,  task  entries,  or  exceptions;  the  object-operation  groups,  which  are 
abstract  data  types,  become  packages.  The  interfaces  among  the  groups  are 
defined  by  the  package  specifications  and  with  clauses,  and  are  controlled  by 
the  compiler  interface  and  type  checking.  Ada's  capability  for  separating  a 
subprogram  specification  and  body  supports  top-down  design  methods  by  allowing 
an  abstract  data  type  to  be  referred  to  once  its  interface  is  specified, 
before  it  is  actually  implemented.  In  addition,  Ada  provides  means  for 
expressing  relationships  among  objects  and  operations  which  are  not  found  in 
many  design  languages.  These  include  the  ability  to  specify  parallel  process¬ 
ing,  asynchronous  data  exchange,  interrupts,  exceptions,  and  machine-dependent 
items . 


Ada  by  itself,  however,  is  not  ideal  for  representing  all  of  the  informa¬ 
tion  which  is  needed  during  design.  Table  15  and  Table  16  indicate  how  the 
information  in  each  paragraph  of  the  MIL-STD-SDS  ( [DoD  82] )  design  documents 
cam  be  represented  in  Ada.  The  paragraph  numbers  are  taken  from  the  associ¬ 
ated  Data  Item  Descriptions  (DIDs)  ( [DoD  82]  R-DID-110  and  R-DID-111) . 


As  these  tables  show,  much  of  the  information  called  for  in  the  documents 
can  only  be  represented  in  Ada  as  comments.  In  general,  this  information 
falls  into  two  classes:  that  which  describes  constraints  or  properties  of  the 
software  which  are  not  directly  reflected  in  its  textual  content,  such  as  exe¬ 
cution  time,  memory  size,  or  data  rates;  and  that  which  requires  reference  to 
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•  .-.Vv  v  A  A A .v-  A  AA  *. .-.'AV- .  -  A  .'•A  A.. V.V-  -.a  .  s'  \ 


Paragraph  number 


Means  of  representation  in  Ada 


1.1 

1.2 

2.1 

2.2 

3 

3.1 

3.1.1 

3.1.2 

3.2 
3.3.1 


3.3.2 

3.3.3 

3.3.4 

3.4 

3.4. X 

3.4. X.1 

3. 4. X. 2 

3. 4. X. 3 

3. 4. X. 4 


3.5.1 


3.5.2 


3. 6. all 

4,  5,  7-9 
6 

10 


Comments,  subprogram  name. 

Comments . 

Comments. 

Comments . 

Comments . 

Package  specifications  and  comments. 
Comments,  or  by  describing  the  hardware 
with  a  package  specification. 

Package  specification  with  comments  for 
data  rates. 

Comments . 

Task  entry  specifications  and  bodies, 
exception  specifications,  handlers, 
representation  specifications. 

Comments,  real-time  control  statements 
(e.g.  DELAY),  PRIORITY  pragma. 

Package  and  representation  specifications. 
Comments,  real-time  statements. 

Subprogram  specification. 

Comments. 

Comments,  subprogram  specification. 
Subprogram  specification,  comments. 
Subprogram  specification,  comments, 
type  and  interface  checking. 

Exception  specifications  find  handlers, 
representation  specifications,  comments. 
Package  specification,  representation 
specifications,  comments. 

Package  specifications,  type  definitions, 
variable  declarations,  constraints, 
representation  specifications. 

Package  specifications,  type  definitions, 
variable  declarations,  constraints, 
representation  specifications,  comments. 
Package  specifications,  representation 
specifications,  comments. 

Intentionally  left  blank  in  DIDs. 

Comments. 

Appendices  -  not  applicable. 
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Table  16.  MIL-STD  SDS  Detailed  Design  Document  Information  in  Ada. 


Paragraph  number 

Means  of  representation  in  Ada 

1.1 

Comments. 

1.2 

Comments,  package  specification. 

2.  all 

Comments . 

3 

Comments. 

3.1 

Subprogram  specifications,  comments. 

3.1.1 

Subprogram  specifications. 

3. 1.1.1 

Comments,  subprogram  specifications. 

3. 1.1. 2 

Comments. 

3. 1.1. 3 

Subprogram  specifications,  bodies,  comments 

3. 1.1. 3. Y  a) 

Comments. 

3. 1.1. 3. Y  b) 

Subprogram  specification,  declaration  part 
of  body. 

3. 1.1. 3. Y  c) 

Subprogram  specification. 

3. 1.1. 3. Y  d) 

Subprogram  specification,  WITH  and  USE 
clauses,  comments. 

3. 1.1. 3. Y  e) 

WITH  and  USE  clauses,  comments. 

3. 1.1. 3. Y  f) 

Comments. 

3. 1.1. 3. Y  g) 

Comments,  subprogram  specification,  body. 

3. 1.1. 3. Y  h) 

Subprogram  specification,  WITH  and  USE 
clauses,  subprogram  body,  comments. 

3. 1.1. 3. Y  i) 

Comments. 

3. 2.I.X. 6 

Task  entry  specifications  and  bodies, 
exception  specifications,  handlers, 

representation  specifications,  comments. 

3. 2.I.X. 7 

Representation  specifications,  comments. 

3. 2.I.X. 8 

Comments,  real-time  statements. 

3. 2.I.X. 9 

Package  specifications,  type  definitions, 
variable  declarations,  constraints, 
representation  specifications,  comments. 

3. 2.I.X. 10 

Package  specifications,  type  definitions, 
variable  declarations,  constraints, 
representation  specifications,  comments. 

3. 2.I.X. 11 

Subprogram  body. 

3. 2.I.X. 12 

Comments. 

3.3 

Representation  specifications,  comments. 

4,  5,  7-9 

6 

Intentionally  left  blank  in  DIDs. 

Comments. 

10 

Appendices  -  not  applicable. 

the  project  information  structure  outside  the  software,  such  as  requirements 
allocation  to  components,  or  references  to  design  analyses.  Supersets  of  Ada, 
such  as  Byron  ( [Gor  83]),  teamed  with  a  hey  concept  of  the  APSE  requirements, 
a  unified  database  for  the  whole  software  development  process,  will  do  much  to 
alleviate  these  problems. 

Another  issue  which  determines  how  effective  Ada  is  as  a  design  represen¬ 
tation  medium  is  what  tools  and  processing  are  available  for  turning  the 
information  in  the  medium  into  the  form  which  is  suitable  for  the  purposes  of 
the  user.  Since  Ada  is  primarily  a  programming  language,  we  tend  to  think  of 
it  as  input  to  a  compiler.  Other  tools  may  use  it  as  input  for  other  pur¬ 
poses,  such  as  generation  of  documents,  flowcharts,  variable  or  module  cross- 
reference  lists,  data  dictionaries,  or  hierarchical  control  trees.  The 
utility  of  Ada  as  a  design  medium,  then,  depends  on  the  analysis  capabilities 
of  a  compiler  and  any  other  tools  that  may  be  used  for  processing  the  design 
representation,  as  well  as  the  expressive  power  of  the  language.  In  partic¬ 
ular,  a  tool  to  measure  metrics  might  prove  useful. 

2. 5. 3.1  Architectural  Design 

Using  the  object-oriented  design  method,  the  architectural  design  begins 
with  the  expression  of  the  informal  problem  solution  in  English.  Once  the 
objects,  operations,  and  their  interfaces  are  defined,  they  may  be  specified 
in  the  top  level  Ada  representation.  This  usually  takes  the  form  of  a  package 
specification  for  each  group  of  objects  and  operations  which  is  used  in  the 
problem  solution,  and  a  subprogram  specification  for  the  solution  itself. 
Preliminary  design  ends  when  enough  iterations  through  the  method  have  been 
made  so  that  the  hierarchy,  control,  and  data  interfaces  ( [Boe  81]  p.  48)  for 
all  components  have  been  defined  to  the  level  of  a  preexisting  software  compo¬ 
nent,  or  a  subprogram  which  "performs  a  single  well-defined  function,  can  be 
developed  by  one  person,  and  is  typically  100  to  300  source  instructions  in 
size"  ([Boe  8l]  p.  49).  As  design  progresses,  the  bodies  of  the  packages  are 
filled  in  with  control  structures  which  use  new,  lower  level,  objects  and 
operations.  These  are  specified  in  new  packages.  The  body  for  the  solution 
subprogram  is  also  filled  in  to  show  how  the  most  abstract  object-operation 
groups  are  used. 

The  first  design  problem  in  [Boo  83]  is  used,  in  the  following  section,  as 
a  sample  for  demonstrating  the  application  of  the  Halstead  metrics.  It  com¬ 
prises  a  subroutine  for  counting  the  leaves  on  a  binary  tree.  The  English 
language  statement  of  the  informal  problem  solution  ([Boo  83]  p.  72)  (the 
informal  architectural  design  specification)  is  reproduced  in  Figure  13  at  the 
end  of  this  section.  Figure  14  reproduces  the  initial  package  specifications 
for  the  counting  leaves  problem  from  [Boo  83] ,  pp.  76-77,  and  Figure  15 
reproduces  the  solution  algorithm  ([Boo  83]  p.  78)  which  uses  these  packages 
as  primitives.  Together  they  constitute  the  architectural  design  for  the 
problem. 
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2. 5. 3. 2  Detailed  Design 


During  detailed  design,  the  algorithms  for  implementing  the  objects  and 
operations  specified  in  the  last  level  of  architectural  design  are  developed 
in  terms  of  objects  and  operations  which  are  not  visible  outside  the  subpro¬ 
gram  which  implements  them.  This  may  require  further  type,  object  and  opera¬ 
tion  definitions,  but  they  are  logically  local:  the  problem  solution  does  not 
use  them  directly,  even  though  they  may  be  part  of  a  library  of  commonly 
available  packages.  There  will  tend  to  be  a  larger  proportion  of  native  Ada 
constructs  and  low  level  utility  routines  used  than  in  the  subprograms  devel¬ 
oped  during  architectural  design.  Here,  decisions  such  as  the  data  structure 
for  local  variables,  or  the  order  of  operations  necessary  to  meet  accuracy 
requirements  are  made. 

Figure  16  shows  the  full  detailed  design  for  the  counting  leaves  problem. 
The  private  parts  of  the  initial  package  specifications  have  been  filled  in, 
and  the  bodies  have  been  written.  The  external  specification  for  another 
package,  F I FO_PACKAGE ,  has  been  introduced,  because  it  is  used  in  the  imple¬ 
mentation  of  the  TREE_PACKAGE .  It  is  assumed  to  be  a  preexisting  package,  so 
its  body  is  not  given  here.  The  solution  statement  has  not  changed  from  that 
given  in  the  architectural  design,  so  it  is  not  repeated. 


2.5.4  Using  Halstead  Metrics  on  Ada 


The  Halstead  metrics  may  be  applied  at  several  stages  during  the  design 
development:  The  informal  English  statement  of  the  problem  solution  may  be 
measured  following  the  techniques  in  [Hal  77]  Chapter  13  ( [Hal  77]  pp.  98-110) 
(this  is  explained  with  the  example  in  a  later  section) ,  and  the  design 
expressed  in  Ada  may  be  measured  using  the  method  described  in  the  following 
section,  at  any  stage  of  the  design  or  coding  phases. 


The  metrics  may  be  used  to  provide  a  way  to  judge  which  of  several  differ¬ 
ent  solution  strategies  is  simpler,  based  on  the  objects  and  operations  in 
which  it  is  stated;  to  estimate  planning  parameters  from  the  architectural 
design;  and  to  provide  a  reasonableness  check  on  the  quality  of  the  design  as 
it  evolves.  Since  the  design  is  expressed  in  actual  Ada  code,  the  same  met¬ 
rics  may  be  applied  to  the  code  as  it  evolves,  to  monitor  complexity  as  chang¬ 
es  are  made.  The  measurements  for  the  architectural  design  can  also  be 
compared  with  those  for  the  English  solution  statement  to  discourage  premature 
implementation  decisions. 


2. 5. 4.1  The  Counting  Method 


A  design  expressed  in  Ada  can  be  viewed  in  two  ways:  as  an  expression  of 
a  problem  solution  in  terms  of  a  language  invented  for  the  occasion,  compris- 

•  *  y 


72  Automating  Software  Design  Metrics 


ing  the  objects  and  operations  needed  for  the  solution;  or  as  an  implementa¬ 
tion  of  that  solution  in  the  language  Ada.  in  the  first  case,  the  objects  and 
operations  developed  during  design  are  viewed  as  if  they  had  always  existed, 
and  had  been  part  of  the  designer's  vocabulary.  The  language  the  designer  is 
speaking  is  not  Ada,  but  an  extremely  specific  one  which  solves  the  problem, 
but  cannot  express  anything  else. 

This  might  be  the  more  useful  point  of  view  for  comparing  competing 
designs  for  conciseness  as  abstract  solutions.  The  second  case,  howevtr,  is  a 
more  accurate  representation  of  what  actually  happens  during  the  design  proc¬ 
ess:  the  designer  invents  the  objects  and  operations  with  which  to  express 
the  solution.  This  corresponds  to  using  the  Ada  constructs  which  create 
types,  variables,  and  subprograms.  It  is  proposed  here  as  the  point  of  view 
more  likely  to  lead  to  a  serviceable  method  of  using  the  Halstead  metrics  for 
comparing  designs  as  practical  solutions,  and  for  predicting  planning  parame¬ 
ters. 


Accordingly,  in  the  method  proposed  below,  lexical  elements  in  Ada  are 
designated  as  operators  or  operands  in  accordance  with  how  the  they  function 
from  the  point  of  view  of  the  person  who  is  writing  in  the  language  Ada,  giv¬ 
ing  directions  to  an  abstract  machine  which  will  create  and  manipulate  the 
objects  specified.  As  design  progresses,  the  abstract  machine  becomes  parti¬ 
cularized  as  the  real  machine. 

This  point  of  view  has  other  benefits:  It  allows  all  the  code  available 
to  be  included  in  the  measurements  at  any  stage,  so  complicated  provisos  are 
not  necessary  for  different  levels  of  detail.  It  allows  different  strategies 
to  be  devised  for  selecting  portions  of  the  the  design  to  be  measured  to  tai¬ 
lor  the  method  for  a  particular  use  of  the  metrics,  such  as  predicting  plan¬ 
ning  parameters.  It  allows  the  same  method  to  be  used  throughout  the  design 
and  coding  phases  and  it  is  consistent  with  earlier  efforts  at  measuring  the 
Halstead  metrics  in  high  level  languages. 

2. 5. 4. 1.1  IDENTIFYING  OPERATORS  AND  OPERANDS 

With  this  philosophy,  the  entities  which  are  operations  in  the  object-or¬ 
iented  design  statements  are  usually  Halstead  operands  of  Ada  keywords  which 
are  Halstead  operators.  For  example,  a  procedure  or  task  entry  call  will  be  a 
verb  phrase  in  the  solution  statement.  In  Ada,  its  declaration  is  viewed  as  a 
command  to  create  a  procedure  or  entry  and  make  accessible  its  name  and 
external  interface.  The  operator  is  the  implicit  "create"  represented  by  the 
reserved  word  procedure  or  entry  and  the  operand  is  the  procedure/entry  name. 
The  invocation  of  the  procedure  or  entry  is  viewed  as  a  "call"  or  "invoke" 
operator  with  the  procedure/entry  name  as  its  operand.  Similarly,  the 
reserved  words  type  and  package  are  further  particularizations  of  the  general 
"create"  operand,  with  the  type  and  package  names  as  operands. 
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The  following  method,  based  on  the  generalized  identification  and  counting 
technique  of  Section  2.2. 3.2  is  proposed  for  identifying  Halstead  operators 
and  operands: 

1.  Comments  are  ignored. 

2.  Pragmas  and  declarations  are  included. 

3.  The  following  are  counted  as  operators: 

All  delimiters,  including  compound  delimiters  (e.g., 

For  paired  grouping  symbols,  such  as  "("  and  ")",  each  pair  is  one 
operator . 

All  reserved  words. 

4.  The  following  are  counted  as  operands: 

All  literals,  including  numeric  literals,  character  literals  (in¬ 
side  the  "'"s),  and  string  literals  (inside  the  M""s). 

All  other  identifiers  which  are  not  reserved  words  in  the  context 
in  which  they  are  used.  These  include  type  names,  formal  parameter 
names,  package  names,  function  names,  procedure  names,  task  names, 
entry  names,  and  exception  names. 

Note  that  since  Ada  allows  the  same  name  to  refer  to  different  entities, 
through  scope  changes  and  overloading,  care  must  be  taken  to  treat  distinct 
entities  as  distinct  operators  and  operands. 

2. 5. 4. 2  Possible  Adjustments  to  the  Counting  Method 

The  counting  metnod  proposed  above  has  been  used  on  the  simple  examples  in 
the  following  section,  but  it  has  not  been  verified  by  application  to  a  sta¬ 
tistically  significant  number  of  design  problems  and  correlation  with  desired 
end  products,  such  as  estimates  for  development  cost.  When  such  data  is  col¬ 
lected,  the  counting  method  might  need  to  be  adjusted  to  perform  better  as  a 
predictor  of  cost  or  yardstick  of  quality.  This  section  lists  some  areas  whe¬ 
re  the  counting  method  might  be  adjusted. 

The  method  used  here  is  based  on  an  expression  of  the  design  in  pure  Ada. 
If  a  superset  is  used,  the  new  design  language  constructs  will  have  to  be 
included  in  the  counting  method.  In  particular,  if  Byron  were  used,  the  Ada 
comments  which  are  Byron  statements  would  need  to  be  included  in  the  metric 
determination,  since  the  Byron  statements  are  Ada  comments.  The  Byron  key¬ 
words  and  other  constructs  would  need  to  be  integrated  with  the  counting  for 
the  Ada  constructs. 
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The  philosophy  for  dividing  operators  and  operands  might  need  to  be  recon¬ 
sidered,  especially  in  the  areas  of  types,  declaration  versus  use  of  items, 
task  objects,  generics,  formal  parameters,  and  renaming.  [Els  78]  discusses 
some  of  these  issues  in  the  context  of  PL/I. 

Use  of  the  use  clause  lets  the  designer  use  objects  and  operations  from 
other  packages  without  having  to  specify  the  full  package  and  entity  name  in 
each  reference.  A  design  written  this  way  will  have  lower  total  operator  and, 
especially,  operand  counts.  Fully  qualified  names  might  be  a  better 
reflection  of  the  amount  of  effort  expended  by  the  designer.  A  metric  evalu¬ 
ation  tool  using  an  APSE  database  would  be  able  to  resolve  references  to 
external  packages,  and  compensate  for  the  use  of  the  use  clause  in  the  design. 

2. 5. 4. 3  Automation  Potential 

Automatic  collection  of  the  Halstead  metric  data  from  an  Ada  represen¬ 
tation  of  a  design  is  clearly  feasible.  It  does,  however,  require  a  tool  as 
complex  as  the  syntactic  and  semantic  analysis  portions  of  a  compiler,  since 
the  design  is  subject  to  the  same  potential  ambiguities  that  a  program  is. 
Other  problems  may  arise  if  the  design  language  is  a  superset  of  Ada.  For 
example,  a  superset  might  allow  inclusion  of  free-form  text  as  a  significant 
part  of  the  design.  Such  a  tool  would  best  be  incorporated  as  part  of  an 
APSE,  since  the  central  database  provides  a  natural  means  for  tracking  pro¬ 
gress  and  monitoring  quality  as  the  development  takes  place. 

2. 5. 4. 4  Example 

The  first  design  problem  in  [Boo  83] ,  counting  the  leaves  on  a  binary 
tree,  is  used  here  as  a  sample  for  demonstrating  the  application  of  the  Hal¬ 
stead  metrics.  The  English  language  solution  statement  (the  informal  archi¬ 
tectural  design  specification) ,  the  Ada  architectural  design  specification, 
and  the  Ada  detailed  design  specification  are  given  in  the  figures  which  fol¬ 
low  the  discussion. 

According  to  Halstead  [Hal  77]  Chapter  13,  the  software  science  parameters 
may  be  measured  from  the  English  solution  statement  by  counting  as  operators 
the  "function  words"  given  in  Table  13.1  ([Hal  77]  p.  100),  punctuation,  cap¬ 
italization,  paragraphing,  and  numbers  with  one  significant  digit;  and  as 
operands  all  other  words.  The  results  of  applying  this  counting  method  to  the 
English  statement  of  the  informal  problem  solution  for  the  counting  leaves 
problem  are  given  in  Table  17  and  Table  18. 

Halstead  also  discusses  adjusting  for  the  redundancy  usual  in  natural  lan¬ 
guage,  which  comes  about  through  using  synonyms  to  make  the  prose  style  more 
interesting.  He  proposes  that  all  distinct  character  patterns  should  be 
counted  as  distinct  operators  or  operands  and  then  the  numbers  for  distinct 
operators  and  operands  should  be  reduced  by  a  factor  to  allow  for  synonyms  and 
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variant  forms,  such  as  plurals.  He  proposes  0.4  as  a  reasonable  factor,  and 
uses  the  difference  between  the  estimated  and  actual  lengths  to  substantiate 
this  choice.  Table  19  shows  the  values  for  the  metrics  with  this  adjustment 
made  to  the  number  of  distinct  operators  and  operands  in  Table  18.  In  this 
case,  picking  the  factor  to  make  the  estimated  length  agree  with  the  actual 
length  of  132  gives  a  value  of  0.554  for  the  factor.  The  metric  values 
obtained  by  using  this  factor  are  also  shown  in  Table  19. 

Table  20  lists  the  operators  and  operands  for  the  architectural  level  of 
the  Ada  design  for  the  same  problem,  obtained  by  using  the  counting  method 
defined  in  the  previous  section.  Table  21  gives  the  Halstead  metric  values 
for  the  architectural  design.  Table  22  and  Table  23  contain  the  operators, 
operands,  and  metric  values  for  the  detailed  Ada  design.  In  each  of  these 
figures,  the  information  is  shown  for  each  major  component  of  the  system,  as 
well  as  the  system  as  a  whole.  That  is,  the  COUNTER_PACKAGE ,  PILE_PACKAGE, 
TREE_PACKAGE,  and  the  main  procedure  numbers  are  shown  for  the  architectural 
design  in  the  columns  labelled  CP,  PP,  TP,  and  main,  respectively.  The 
detailed  design  figures  include,  in  addition,  a  column  labelled  FP,  for  the 
FIFO_PACKAGE. 

2. 5. 4. 5  Analysis  of  the  Counting  Leaves  Example 

This  example  shows  that  the  Halstead  metrics  may  be  measured  from  an  Ada 
design  representation,  but  the  utility  of  the  data  as  a  predicting  and  con¬ 
trolling  tool  remains  to  be  verified  on  more,  larger  samples.  As  may  be  seen 
from  the  figures,  the  metric  values  increase  with  the  addition  of  detail  to 
the  design,  as  expected.  The  correspondence  between  the  program  length  esti¬ 
mator  and  the  program  length  metric  also  improves  with  additional  detail.  It 
is  likely  that  the  metrics  can  be  used  to  compare  alternate  designs,  as  long 
as  they  are  compared  at  the  same  level  of  detail. 

The  Halstead  metrics  will  favor  the  design  which  is  expressed  using  fewer 
objects  and  operations,  since  they  effectively  correspond  to  the  operands  and 
operators  counted  in  determining  the  Halstead  measures.  This  encourages  the 
designer  to  think  about,  and  express,  the  solution  in  terms  which  are  high 
level,  as  close  as  possible  to  the  level  of  the  problem  statement,  rather  than 
in  terms  of  the  primitives  of  the  system  upon  which  it  will  be  implemented. 
There  is  some  evidence  that  the  object-oriented  design  method  encourages  this 
kind  of  design,  in  that  the  estimated  language  levels  for  the  architectural 
design  are  larger  than  those  for  the  detailed  design,  and  the  estimated  lan¬ 
guage  level  for  the  main  subprogram  is  larger  than  those  for  the  supporting 
packages. 

Possibly,  sets  of  metric  values  for  components  at  different  levels  of 
detail  could  be  used  to  develop  a  characteristic  profile  for  how  the  values 
change  as  design  progresses.  The  profile  might  then  be  used  as  a  guideline 
for  estimating  development  cost  parameters  for  new  modules,  or  for  setting 
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bounds  on  a  reasonable  growth  rate  for  the  metrics  during  the  design  process. 
Any  module  which  exhibited  an  out-of-bounds  growth  rate  would  be  suspect.  The 
profile  might  depend  on  following  a  particular  design  method,  such  as  the 
object-oriented  method,  in  which  the  changes  from  level  to  level  are  well 
defined  and  constrained. 


Keep  a  pile  of  the  parts  of  the  tree  that  have  not  yet  been 
counted.  Initially,  get  a  tree  and  put  it  on  the  empty  pile; 
the  count  of  the  leaves  is  initially  set  to  zero.  As  long  as 
the  pile  is  not  empty,  repeatedly  take  a  tree  off  the  pile  and 
examine  it.  If  the  tree  consis  of  a  single  leaf,  then 
increment  the  leaf  counter  and  throw  away  that  tree.  If  the 
tree  is  not  a  single  leaf  but  instead  consists  of  two  subtrees 
split  the  tree  into  its  left  and  right  subtrees  and  put  them 
back  on  the  pile.  Once  the  pile  is  empty,  display  the  count 
of  the  leaves. 


Figure  13.  English  Language  Problem  statement  for  Counting  Leaves 
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package  counter_package  is 

type  COUNTER_TY PE  is  limited  private; 
procedure  DISPLAY  (COUNTER  :  in  COUNTERJTYPE) ; 
procedure  INCREMENT  (COUNTER  :  in  out  COUNTERJTYFE) ; 
procedure  ZERO  (COUNTER  :  out  COUNTER_TYPE) ; 
private 
•  •  « 

end  COUNTER_PACKAGE ; 

with  TREE_PACKAGE; 
package  PILE_PACKAGE  is 

type  PILE_TYPE  is  limited  private; 
function  IS_NOT_EMPTY  (PILE  :  in  PILEJTYPE) 
return  BOOLEAN; 

procedure  PUT  (TREE  :  in  out  TREE_PACKAGE . TREE_T YPE ; 

ON  :  in  out  PILE_TYPl) ; 

procedure  PUT_INITIAL  (TREE  :  in  out  TREE_PACKAGE . TREE_TYPE ; 

ON  :  in  out  PILE_TYPE) ; 

procedure  TAKE  (TREE  s  out  TREE_PACKAGE.TRiE_TYPE; 

OFF  :  In  out  PILE  TYPE); 


private 
•  •  • 

end  P I LE_P ACKAGE ; 

package  TREE_P ACKAGE  is 
type  TREE_TYPE  is  private; 

procedure  GET_INITIAL  (TREE  ;  out  TREE_TYPE) ; 
function  I S_S I N GLE_LEAF  (TREE  :  in  TREE_TYPE) 
return  BOOLEAN; 

procedure  SPLIT  (TREE  ;  in  out  TREE_TYPE; 

LEFT_INTO  :  out  TREE_TYPE ; 

RIGHT_INTO:  out  TREE_TYPE) ; 

procedure  THROW_AWAY  (TREE  :  in  out  TREE_TYPE) ; 
private 

end  TREE_P ACKAGE ; 


Figure  14.  Ada  Architectural  Design  Specification  for  Counting  Leaves 
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With  COUNTER_PACKAGE,  PILE_PACKAGE,  TREE_PACKAGE ; 
Use  COUNTER_PACKAGE ,  P I LE_P ACKAGE ,  TREE_P ACKAGE ; 
procedure  c5uNT_LEAVES_0N_BINARY_TREE  il 


LEAF_COUNT  :  COUNTER  TYPE; 

LEFT_SUBTREE  :  TREEJTYPE; 

PILE  :  PILE~TYPE; 

RIGHT_SUBTREE  :  TREEJTYPE; 

TREE  :  TREE_TYPE; 

begin 

GET_INITIAL (TREE) ; 

PUT_INITIAL(TREE,  ON  =>  PILE); 

ZERO ( LEAF_COUNT ) ; 

While  IS_NOT_EMPTY (PILE) ; 
loop 

TAKE (TREE,  OFF  =>  PILE); 
if  IS_SINGLE_LEAF (TREE)  then 
INCREMENT (LEAF_COUNT) ; 

THROW_AWA Y ( TREE ) ; 
else 

SPLIT (TREE, 

LEFT_INTO  =>  LEFT_SUBTREE , 
RIGHT_INTO  =>  RIGHT_SUBTREE) ; 
PUT (LEFT_SUBTREE ,  ON  =>  PILE); 

PUT (RIGHT_SUBTREE,  ON  =>  PILE); 
end  if; 
end  loop; 

DISPLAY  (LEAF_COUNT) ; 
end  COUNT_LEA VES_ON_B I N AR Y_TREE ; 


Figure  15.  Ada  Solution  Statement  for  Counting  Leaves. 
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package  counter_package  is 

type  COUNTERJTYPE  is  limited  private; 
procedure  DlIpLAY  (COUNTER  :  in  COUNTERJTYPE) ; 
procedure  INCREMENT  (COUNTER  :  in  out  COUNTERJTYPE) ; 
procedure  ZERO  (COUNTER  :  out  COUNTERJTYPE) ; 
private 

type  COUNTERJTYPE  is  NATURAL; 
end  COUNTER_PACKAGE ; 

With  TEXT_IO; 

package  body  counter_package  is 

procedure  DISPLAY  (COUNTER  :  in  COUNTERJTYPE )  is 

package  COUNTER_IO  is  new  TEXT_IO. INTEGER_IO (COUNTERJTYPE) ; 
begin 

COUNTER_IO . PUT (COUNTER) ; 
end  DISPLAY; 

procedure  INCREMENT  (COUNTER  :  in  out  COUNTERJTYPE)  is 
begin 

COUNTER  :=  COUNTER  +  1; 
end  INCREMENT; 

procedure  ZERO  (COUNTER  :  out  COUNTERJTYPE)  is 
begin 

COUNTER  :=  0; 
end  ZERO; 

end  COUNTER_PACKAGE; 


With  F I FO_P ACKAGE ; 

With  TREE_P ACKAGE; 
package  P I LE_P ACKAGE  is 

type  PILE_TYPE  is  limited  private; 
function  IS_NOT_EMPTY  (PILE  :  in  PILE_TYPE) 
return  BOOLEAN; 

procedure  PUT  (TREE  :  in  out  TREE_P ACKAGE. TREE_TYPE; 

ON  :  in  out  PILE_TYPE) ; 

procedure  PUT_INITIAL  (TREE  :  in  out  TREE_P ACKAGE . TREE_TYPE ; 

ON  :  in  out  PILE_TYPE) ; 

procedure  TAKE  (TREE  :  out  TREE_P ACKAGE. TREE_TYPE; 

OFF  :  In  out  PILE_TYPE) ; 

private 

package  TREE_QUEUE  is  new  FIFO_PACKAGE(TREE_TYPE) ; 
type  PILE_TYPE  is  TREE_QUEUE . QUEUE_TYPE ; 
end  PILE  PACKAGE; 


« 


with  TREE_QUEUE; 

package  body  P I LE_PACKAGE  is 

function  I S_NOT_EMPT Y  (PILE  :  in  PILEJTYPE) 
return  boolean  is 
begin 

return  not  TREE_QUEUE.IS_EMPTY (PILE) ; 
end  IS_NOT_EMPTY; 

procedure  PUT  (TREE  :  in  out  TREE_P  ACKAGE.  TREE_TYPE; 

ON  :  in”out  PILE_TYpI)  is 

begin 

TREE_QUEUE. APPEND  (ELEMENT  =>  TREE,  TO  =>  ON); 
end  PUT? 

procedure  PUT_INITIAL  (TREE  :  in  out  TREE_PACKAGE.TREE_TYPE; 

ON  :  in  OUt  PILi_TYPE) 

renames  PUT; 

e 

procedure  TAKE  (TREE  :  out  TREE_PACKAGE . TREE_TYPE ; 

OFF  :  In  OUt  PILEJTYPE)  is 

begin 

TREE_QUEUE . TAKE  (ELEMENT  =>  TREE,  OFF  =>  OFF); 
end  TAKE; 

end  P I LE_P ACKAGE ; 

Figure  16.  Ada  Detailed  Design  for  Counting  Leaves  -  P I LE_P ACKAGE .  (Part 
3  of  8) 
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package  TREE_PACKAGE  is 
type  TREEJTYPE  is  private; 

procedure  GET_INITIAL  (TREE  :  out  TREE_TYPE) ; 
function  IS_S I NGLE_LEAF  (TREE  :  in  TREEJTYPE) 
return  BOOLEAN; 

procedure  SPLIT  (TREE  :  in  out  TREE_TYPE; 

LEFT_INTO  :  out  TREE_TYPE; 

RIGHT_INTO:  out  TREEJTYPE) ; 

procedure  throw_away  (tree  :  in  out  tree_TYPE) ; 
private 
type  NODE; 

type  TREE_TYPE  is  access  NODE; 
type  NODE_VALUE_TYPE  is  STRING{1. .10) ; 
type  node  is 
record 

LEFT  s  TREE_TYPE;  # 

VALUE  :  NODE_VALUE_TYPE ; 

RIGHT  :  TREE_TYPE; 

end  record; 
end  TREE  PACKAGE; 


With  DIRECT_IO; 

package  body  TREE_PACKAGE  is 

procedure  get_initial  (tree  :  out  tree_type)  is 

—  Assume  that  the  tree  information  is  in  a  direct 

—  access  file.  Each  record  consists  of  the  information 

—  for  one  node  of  the  tree,  consisting  of  the  value  for 

—  the  node,  the  file  index  of  the  top  node  of  the  left 

—  subtree,  and  the  file  index  of  the  top  node  of  the 

—  right  subtree,  in  that  order. 

—  The  file  index  for  the  subtree  will  be  zero 

—  if  the  node  is  a  leaf. 

—  The  topnode  for  the  entire  tree  is  in  record  1. 
type  TREE_RECORD_TYPE; 

package  tree_io  Is  new  direct_io (tree_record_type) ; 
type  tr£e_record_type  is 
record 

VALUE  :  NODE_VALUE_TYPE; 

LEFT_INDEX  s  TREE_IO.PC)IlTIVE_COUNT; 

RIGHT_INDEX:  TREE_IO.POSITIVE~COUNT; 
end  record; 

TREE_RECORD :  TREE_RECORD_T YPE ; 

DATA_FILE  :  TREE_I 0 . F I LE_T YPE ; 

With  TREE_IO; 

procedure  GET_SUBTREE  (TREE  s  out  TREE_TYPE; 

RECORD_I NDEX :  in  TREE_IO.POSITIVE_COUNT; 
FILE  t  in  TREE_IO.FILE_TYPE; 

TREE_RECORD  :  in  OUt  TREE_RECORD_TYPE 
)  is 


Figure  16.  Ada  Detailed  Design  for  Counting  Leaves  -  TREE  PACKAGE. 
5  of  8) 
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begin 

if  R£CORD_I NDEX  =  TREE_IO.POSITIVE_COUNT(0) 
then 
null; 
else 

TREE_ I 0 . READ (FILE,  ITEM  =>  TREE_RECORD , 

FROM  =>  RECORD_INDEX) ; 

TREE  :=  new  NODE' (LEFT  =>  null, 

VALUE  =>  TREE_RECORD. VALUE, 

RIGHT  =>  null) ; 

GET_SUBTREE (TREE  =>  TREE. LEFT, 

RECORD_INDEX  =>  TREE_RECORD.LEFT_INDEX, 
FILE  =>  FILE, 

TREEJRECORD  =>  TREE_RECORD) ; 

GET_SUBTREE (TREE  *>  TREE. RIGHT, 

RECORD_INDEX  =>  TREE  RECORD . R I GHT_ I NDEX , 
FILE  =>  FILE, 

TREE_RECORD  =>  TREE_RECORD) ; 

end  if; 

end  GET_SUBTREE ; 
begin 

TREE_IO . OPEN  (DATA_FILE, 

MODE  =>  IN_FILE, 

NAME  =>  "Put  in  implementation  detail  here”, 

FORM  =>  "Put  in  implementation  detail  here"); 
GET_SUBTREE (TREE  =>  TREE, 

RECORD_I NDEX  =>  TREE_IO.POSITIVE_COUNT(1) , 

FILE  =>  DATAJFILE, 

TREE_RECORD  =>  TREE_RECORD ) ; 

TREE_IO. CLOSE  (DATA_FILE) ; 

exception 

—  Fill  in  exception  processing  during  implementation, 
when  DATA_ERROR  => 
null; 


Figure  16.  Ada  Detailed  Design  for  Counting  Leaves  -  TREE_PACKAGE .  (Part 
6  Of  8) 
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when  DEVICE_ERROR  => 
null; 

When  END_ERROR  => 
null; 

When  NAME_ERROR  => 
null; 

When  STATUS_ERROR  => 
null; 

when  USE_ERROR  => 
null; 

end  GET_INITIAL; 

function  IS_SINGLE_LEAF  (TREE  ;  in  TREE_TYPE) 
return  boolean  is 
begin 

return  (TREE. LEFT  =  null)  and  (TREE. RIGHT  =  null); 
end  IS_SINGLE_LEAF; 

procedure  SPLIT  (TREE  :  in  out  TREE_TYPE; 

LEFT_INTO  ;  out  TREE_TYPE ; 

RIGHT_INTO:  out  TREE_TYPE)  is 

begin 

LEFT_INTO  : =  TREE . LEFT ; 

RIGHT_INTO  ;=  TREE. RIGHT; 

THROW_AWAY (TREE) ; 
end  SPLIT; 


procedure  throw_away  (tree  :  in  out  tree_type)  is 
begin 

—  Assume  that  deallocation  and  garbage  collection  are 
—  done  by  the  system. 

TREE  ;=  null; 
end  THROW_AWAY ; 
end  TREE  PACKAGE; 


Figure  16.  Ada  Detailed  Design  for  Counting  Leaves  -  TREE_PACKAGE .  (Part 
7  of  8) 
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generic 

type  QUEUE_ELEMENT_VALUE_TYPE  is  private; 
package  FIFO_PACKAGE  is 

type  QUEUE_TYPE  is  limited  private; 

EMPTY_QUEUE:  constant  QUEUE_TYPE; 
function  (QUEUEl:  in  QUEUE_TYPE ; 

QUEUE2:  in  QUEUE_TYPE) 

return  BOOLEAN; 

function  IS_EMPTY  (QUEUE  :  in  QUEUE_TYPE) 
return  BOOLEAN; 

procedure  APPEND  (ELEMENT:  in  QUEUE_ELEMENT_VALUE_TYPE ; 

TO  :  in  out  QUEUE_TYPE) ; 

procedure  TAKE  (ELEMENT:  out  QUEUE_ELEMENT_VALUE_TYPE; 

OFF  :  in  out  QUEUE_TYPE) ; 

private 

type  QUEUE_ELEMENT_TYPE ; 

type  QUEUE_TYPE  is  access  QUEUE_ELEMENT_TYPE ; 
type  QUEUE_ELEMENT_TYPE  is 
record 

VALUE:  QUEUE_ELEMENT_VALUE_TYPE; 

REST  :  QUEUE_TYPE ; 
end  record; 
end  FIFO  PACKAGE; 


Figure  16.  Ada  Detailed  Design  for  Counting  Leaves  -  F I FO_P ACKAGE . 
8  of  8) 
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Table  17.  Operators  and  Operands  m  English  Statement  for  Counting  Leaves 


HALSTEAD  METRIC 


OPERATORS 


<paragraph> 
<upper  case> 


[BOO  83]  DESIGN  PROBLEM  ONE  -  ENGLISH 


right 

instead 


COUNT  OPERANDS 


Off 

put 

set 

back 

leaf 

left 

long 

pile 

take 

tree 

count 

empty 

parts 

split 

throw 

leaves 

single 

counted 

counter 

display 

examine 

consists 

subtrees 

increment 

initially 

repeatedly 


COUNT 
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►V'-.y.y.y,  .-.y. 


HALSTEAD  METRIC  [BOO  83]  DESIGN  PROBLEM  ONE  -  ENGLISH 


DISTINCT  OPERATORS 

33 

DISTINCT  OPERANDS 

26 

TOTAL  OPERATORS 

84 

TOTAL  OPERANDS 

48 

VOCABULARY 

59 

DESIGN  LENGTH 

132 

ESTIMATED  LENGTH 

289 

PERCENT  OFF 

-119 

DESIGN  VOLUME 

777 

POTENTIAL  VOLUME 

26 

ESTIMATED  DESIGN  LEVEL 

0.03 

INTELLIGENCE  CONTENT 

25 

ESTIMATED  LANGUAGE  LEVEL 

0.8 

ESTIMATED  EFFORT 


23,654 


TaDle  19.  Halstead  Metric  Values  for  English  Statement  Adjusted  for 
Redundancy 


HALSTEAD  METRIC 


[BOO  83]  DESIGN  PROBLEM  ONE  -  ENGLISH 


Redundancy  factor  * 


ESTIMATED  LANGUAGE  LEVEL  0.6 


ESTIMATED  EFFORT  18,338 


0.554 


DISTINCT  OPERATORS 

13.2 

18.3 

DISTINCT  OPERANDS 

10.4 

14.4 

TOTAL  OPERATORS 

84 

84 

TOTAL  OPERANDS 

48 

48 

VOCABULARY 

23.6 

32.7 

DESIGN  LENGTH 

132 

132 

ESTIMATED  LENGTH 

84 

132 

PERCENT  OFF 

36 

DESIGN  VOLUME 

602 

664 

POTENTIAL  VOLUME 

20 

22 

ESTIMATED  DESIGN  LEVEL 

0.03 

0.03 

INTELLIGENCE  CONTENT 

20 

22 

20,256 


HALSTEAD  METRIC  [BOO  83]  DESIGN  PROBLEM  ONE  -  ARCH  DES 


OPERATORS  CP  PP  TP  main  system 


. 

0 

3 

0 

0 

3 

(  ) 

3 

4 

4 

12 

23 

? 

5 

8 

21 

44 

9 

spIm 

0 

10 

10 

: 

3 

mm 

6 

5 

21 

=  > 

m 

gEl 

0 

6 

6 

begin 

n 

0 

1 

1 

else 

m 

mm 

■a 

1 

1 

end 

— 

mm 

Si 

3 

6 

function 

- 1 

n 

H 

0 

2 

if 

m 

Kl 

0 

2 

2 

in 

2 

6 

3 

0 

11 

is 

2 

2 

2 

1 

7 

limited 

mm 

0 

0 

2 

loop 

0 

2 

2 

out 

2 

5 

0 

13 

package 

1 

1 

0 

3 

private 

2 

2 

2 

0 

6 

procedure 

3 

3 

3 

1 

10 

return 

mm 

mm 

1 

0 

2 

then 

mm 

■If; 

0 

1 

1 

type 

D 

1 

.  0 

3 

use 

0 

1 

1 

while 

n 

0 

1 

1 

with 

m 

n 

0 

1 

2 

DISTINCT  OPERATORS 

12 

16 

13 

16 

25 

TOTAL  OPERATORS 

26 

50 

38 

69 

183 

cn  w 


HALSTEAD  METRIC 


[BOO  83]  DESIGN  PROBLEM  ONE  -  ARCH  DES 


CP  PP  TP 


system 


RIGHT_SUBTREE 

SPLIT 

TAKE(PP) 

THROW_AWAY 
TREE (PUT) 

TREE (PUT_INITIAL) 
TREE (TAKE) 

TREE (GET_INITIAL) 
TREE ( I S_S I N GLE_LEAF ) 
TREE (SPLIT) 

TREE (THROW_AWAY ) 

TREE (main) 
TREE_PACKAGE 
TREE_TYPE 
ZERO 


DISTINCT  OPERANDS 
TOTAL  OPERANDS 


HALSTEAD  METRIC 


[BOO  83]  DESIGN  PROBLEM  ONE  -  ARCH  DES 


CP 

PP 

TP  main 

system 

DISTINCT  OPERATORS 

12 

16 

13 

16 

25 

DISTINCT  OPERANDS 

8 

16 

13 

28 

40 

TOTAL  OPERATORS 

26 

50 

38 

69 

183 

TOTAL  OPERANDS 

12 

26 

20 

54 

112 

VOCABULARY 

20 

32 

26 

44 

65 

DESIGN  LENGTH 

38 

76 

58 

123 

295 

ESTIMATED  LENGTH 

67 

128 

96 

199 

329 

PERCENT  OFF 

-76 

-68 

-66 

-61 

-12 

DESIGN  VOLUME 

164 

380 

273 

672 

1777 

ESTIMATED  DESIGN  LEVEL 

0.1 

0.1 

0.1 

0.1  0.03 

INTELLIGENCE  CONTENT 

18 

29 

27 

44 

51 

ESTIMATED  LANG  LEVEL 


ESTIMATED  EFFORT 


1478  4940  2726  10360 


62181 


Table  22.  Operators  and  Operands  in  Detailed  Design  for  Counting 
Leaves.  (Part  2  of  6) 
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Table  22.  Operators  and  Operands  in  Detailed  Design  for  Counting 
Leaves.  (Part  6  of  6) 


HALSTEAD  METRIC  [BOO  83]  DESIGN  PROBLEM  ONE  -  DET  DES 


OPERANDS 

CP 

pp 

TP 

main 

FP 

system 

TREE (mainproc) 

0 

0 

0 

7 

0 

7 

TREE  10 

0 

0 

12 

0 

0 

12 

TREE  PACKAGE 

0 

7 

4 

2 

0 

13 

TREE_RECORD_T Y  PE 

TREE  RECORD 

0 

0 

5 

0 

0 

5 

(GET_INITI AL) 

TREE  RECORD 

0 

0 

2 

0 

0 

2 

(GET  SUBTREE) 

0 

0 

10 

0 

0 

10 

TREE  QUEUE 

0 

6 

0 

0 

0 

6 

TREE  TYPE 

0 

MM 

17 

3 

0 

27 

USE  ERROR 

0 

Bi 

1 

0 

0 

1 

VALUE (FIFO) 

0 

0 

0 

0 

1 

1 

VALUE (NODE) 

VALUE 

0 

0 

0 

0 

2 

(TREE  RECORD  TYPE) 

0 

0 

0 

0 

2 

ZERO 

3 

0 

1 

0 

4 

0 

■9 

0 

0 

0 

2 

1 

■9 

0 

2 

0 

0 

3 

10 

Put  in  implementation 

0 

0 

1 

0 

0 

1 

detail  here 

0 

0 

2 

0 

0 

2 

DISTINCT  OPERANDS 

m 

27 

28 

18 

■B 

TOTAL  OPERANDS 

K9 

79 

54 

33 

Mm 

LOO 
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Table  23.  Halstead  Metric  Values  for  Detailed  Design  for  Counting  Leaves 


HALSTEAD  METRIC 

[BOO  83] 

DESIGN 

PROBLEM  ONE 

-  DET  DES 

CP 

PP 

TP  main 

FP  system 

DISTINCT  OPERATORS  19  23  35  16  20  45 
DISTINCT  OPERANDS  15  27  52  28  18  105 
TOTAL  OPERATORS  75  133  279  69  69  625 
TOTAL  OPERANDS  41  79  169  54  33  376 
VOCABULARY  34  50  87  44  38  150 
DESIGN  LENGTH  116  212  448  123  102  1001 
ESTIMATED  LENGTH  139  232  476  199  161  952 
PERCENT  OFF  -20  -10  -6  -61  -58  5 
DESIGN  VOLUME  590  1196  2886  672  535  7236 
ESTIMATED  DESIGN  LEVEL  0.04  0.03  0.02  0.06  0.05  0.01 
INTELLIGENCE  CONTENT  23  36  51  44  29  90 
ESTIMATED  LANG  LEVEL  0.9  1.1  0.9  2.8  1.6  1.1 
ESTIMATED  EFFORT  62181  40260  164166  10360  9814  583018 


15  27 


16  20 
28  18 


75 

133 

279 

69 

69 

41 

79 

169 

54 

33 

34 

50 

87 

44 

38 

116 

212 

448 

123 

102 

139 

232 

476 

199 

161 

-20 

-10 

-6 

-61 

-58 

590 

1196 

2886 

672 

535 

i.04 

0.03 

0.02 

0.06 

0-05 

23 

36 

51 

44 

29 

0.9 

1.1 

0.9 

2.8 

1.6 
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3.0  USING  DESIGN  METRICS,  A  SUPPORTING  METHODOLOGY 


This  section  outlines  a  methodology,  consistent  with  the  RADC  software 
quality  framework,  for  using  design-aid  tools  and  design  metrics.  It 
envisions  a  situation  in  which  such  tools  and  metrics  are  part  of  an  inte¬ 
grated  software  engineering  environment  which  is  used  to  support  all  phases  of 
software  development.  Using  this  approach,  it  is  possible  to 

1.  Evaluate  competing  software  designs, 

2.  Estimate  software  project  planning  parameters, 

3.  Monitor  software  product  quality. 

Previous  sections  of  this  report  have  described  and  illustrated  various 
software  design  media,  and  have  shown  how  metrics  can  be  defined  for  measuring 
certain  software  quality  criteria.  In  particular,  the  CSDL  tool  DARTS  was 
introduced  and  used  to  illustrate  the  automatic  generation  of  McCabe  and  Hal¬ 
stead  metrics  based  on  the  information  in  a  DARTS  design  database.  An  example 
was  also  given  of  the  use  of  an  Ada  PDL  as  a  design  medium,  and  Halstead  met¬ 
rics  were  extracted  in  a  similar  fashion.  Both  the  Halstead  and  McCabe  met¬ 
rics  provide  a  means  for  assessing  the  complexity  (or  inversely,  simplicity) 
of  competing  designs.  The  Halstead  metric  is  also  capable  of  indicating  con¬ 
ciseness  of  a  design,  as  discussed  previously. 

This  section  begins  with  the  definition  of  a  method  for  projecting  project 
costs  and  schedules  based  on  metric  data  taken  during  the  early  phases  of  a 
project.  It  then  describes  in  more  detail  the  anticipated  use  of  design  met¬ 
rics  by  both  software  development  and  program  office  personnel. 


3.1  PROJECTING  PROJECT  COSTS  AND  SCHEDULES 


To  estimate  costs  and  schedules  in  the  early  phases  of  a  software  develop¬ 
ment  project,  one  must  adopt  a  cost  estimation  method,  gather  any  needed  data, 
estimate  required  parameters,  and  carry  out  the  required  computations.  Boehm 
reviews  a  number  of  cost  estimation  methods  [Boe  8l] ,  and  recommends  using  a 
combination  of  techniques  including: 
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•  Top-down  estimates  based  on  expert  opinion  and  previous  experience,  and 

•  Bottom-up  estimates  (module  by  module)  using  an  algorithmic  model. 

Although  there  is  no  substitute  for  expert  opinion  and  previous  experi¬ 
ence,  algorithmic  models  have  been  found  increasingly  useful  as  a  base  for 
estimating  project  cost  and  schedule.  Boehm's  COCOMO  model  [Boe  8l]  is  an 
example  of  an  estimation  method  that  has  been  widely  used  and  adopted  by  many 
organizations.  It  has  the  advantage  of  being  well  documented,  and  has  been 
validated  using  data  collected  from  63  completed  projects.  As  an  example,  the 
COCOMO  intermediate  model  estimated  software  cost  within  20  percent  of  project 
actual  cost  68  percent  of  the  time. 


3.1.1  An  Algorithmic  Estimation  Method 


Halstead  presents  an  algorithmic  estimation  method  which  has  certain 
desirable  features,  although  it  has  been  criticized  for  some  of  its  assump¬ 
tions.  It  is  based  on  two  aspects  of  software  science  theory: 

•  The  effort  measure  E,  and  its  relation  to  programming  effort,  and 

•  The  potential  volume  v»,  and  the  ability  to  infer  software  science  met¬ 
rics  from  v*  and  the  implementation  language  level  A  . 

« 

Halstead  suggests  that  once  E  is  known,  an  estimate  for  the  programming 
effort  can  be  obtained  from: 

T  *  E/S 

where  T  is  programming  time  and  S  is  the  Stroud  number.  Halstead  used  the 
Stroud  number  as  a  measure  of  the  number  of  elementary  mental  discriminations 
a  programmer  would  make  per  unit  time.  He  cited  the  range  for  S  as  from  5  to 
20  discriminations  per  second,  and  most  commonly  used  18  discriminations  per 
second  (in  which  case  T  is  measured  in  seconds).  This  approach  has  been  crit¬ 
icized  recently  as  an  incorrect  application  of  the  results  of  cognitive  psy¬ 
chology  studies  [cou  83] ,  although  a  certain  amount  of  empirical  evidence  has 
been  amassed  in  its  favor. 

To  obtain  an  estimate  of  E  for  an  implementation,  Halstead  suggests  using 
the  potential  volume  V*  and  the  implementation  language  level  A  .  The  poten¬ 
tial  volume  v*  is  a  measure  of  the  volume  of  an  algorithm  .in  its  minimal  form, 
namely,  a  "built-in”  function  which  computes  the  algorithm  from  a  list  of  its 
input  and  output  parameters.  If  the  number  of  such  parameters  (operators)  is 
designated  12*  ,  then  the  minimal  vocabulary  1*  is  computed  as 

H*  =  2  +  r)2* 
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where  the  operand  count  is  taken  as  2  to  account  for  the  name  of  the  procedure 
and  the  assignment  operator  (or  grouping  symbol) .  The  potential  volume  is 
computed  from 


v*  =  n*  iog2  n* 


The  language  level  A  was  proposed  as  a  parameter  that  would  characterize 
a  programming  language  in  terms  of  expressive  power.  Halstead  defined  it  in 
terms  of  the  program  level  L  and  the  volume  V  as 

A  =  L2V  =  LV* 

By  analyzing  programs  written  in  a  number  of  different  languages,  he  was  able 
to  measure  A  as  1.53  for  PL/1,  1.14  for  Fortran,  and  0.88  for  CDC  assembly 
language,  although  these  values  had  large  variances.  Subsequent  research  has 
failed  to  corroborate  these  results  for  other  sets  of  data,  and  the  claim  for 
constancy  of  the  language  level  must  now  be  regarded  as  questionable  [She  83] . 

Nevertheless,  Halstead  gives  the  following  formula  for  estimating  E  [Hal 
77] 

E  =  (V*) 3/A2 


i 


.\>v 
%’  * 


Vy 


In  other  words,  by  estimating  A  for  the  implementation  language  and  by  know¬ 
ing  v*  from  a  count  of  the  inputs  and  outputs  of  the  algorithm,  one  can  esti¬ 
mate  E  for  the  implementation,  and  then  calculate  T. 

In  the  following,  it  is  proposed  to  use  the  potential  volume  and  language 
level  in  order  to  estimate  the  program  length  N  instead  of  E,  and  thus  avoid 
use  of  the  controversial  Stroud  number.  Although  a  value  must  be  selected  for 
the  language  level,  it  does  not  otherwise  enter  into  the  method  and  in  partic¬ 
ular  does  not  need  to  be  measured.  The  utility  of  the  procedure  must  be 
empirically  determined. 


The  program  length  N  can  be  directly  related  to  length  in  thousands  of 
delivered  source  instructions  (KDSI),  and  hence  estimates  of  cost  and  schedule 
can  be  derived  using  Boehm's  C0C0M0  model  or  other  models.  For  example,  in 
the  basic  COCOMO  model 


y.y; 


.V _\ 

-  <y  i 

vS\ 

►V.'v 

"A  V 


MM  =  2.4  (KDSI) 1,05 
0*38 

TDEV  =  2.5  (MM) 
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where  MM  is  effort  in  mam-months  and  TDEV  is  development  time  in  months,  and 
the  so-call#d  organic  development  mode  is  assumed  (see  [Boe  8l] ) .  Note  that 
in  talking  about  delivered  source  instructions  the  following  comments  apply. 

1.  Delivered  means  any  software  developed  with  the  same  rigor  as  as  a 
deliverable  product,  e.g.,  software  developed  with  reviews,  test  plans, 
documentation,  etc. 

2.  Source  instructions  exclude  comments  but  include  job  control  language, 
format  statements,  and  data  declarations. 

Note  also  that  the  above  formulas  exclude  the  effort  required  for  the  plans 
and  requirements  phase,  and  that  good  management  practices  are  assumed. 

Halstead's  length  N  may  be  related  to  KDSI  as  follows: 

N  =  a  x  b  x  KDSI  x  103 

where  a  is  the  ratio  of  executable  to  total  source  statements  (since  only  exe¬ 
cutable  source  statements  are  counted  in  Halstead's  method),  and  b  is  the  num¬ 
ber  of  operators  and  operands  in  one  source  statement.  Halstead  suggested 
using  .5  for  a,  and  for  b,  7.5  for  a  high  level  language  and  2.7  for  assembly 
language  [Hal  77,  Hal  78a] .  using  the  value  for  a  high  level  language,  one 
finds 

KDSI  =  (2.667  x  10  )  N 


To  find  an  estimate  of  the  length  N,  one  first  finds  the  volume  estimate 
using  Halstead's  relation  [Hal  77] 

v  =  (V*)2/2 

By  definition,  the  volume  is  related  to  the  length 

V  =  N  log2  (n/2) 

where  n  is  the  vocabulary.  Employing  the  approximation,  nx  =  n2  =  n/2  , 

one  has 

n  =  n  log 2  (n) 

Thus  for  a  given  V«  and  A  ,  one  must  find  n  such  that 
f(n)  =  n  log 2 (n/2)  i°g2n  -  /^  -  0 

Once  H  is  found,  then  N  is  found  from  the  preceeding  formula. 
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Gaffney  presents  an  alternative  method  for  estimating  V  that  has  the 
advantage  of  not  involving  the  language  level  [Gaf  81] ,  Out  it  appears  to  be 
of  use  only  for  relatively  large  modules. 

One  can  apply  this  method  to  the  design  taken  as  a  whole,  but  it  is  pref¬ 
erable  to  use  data  from  the  architectural  design  to  estimate  the  length  of 
each  of  the  modules  separately,  and  then  add  to  get  the  total  design  length. 
Thus,  the  technique  provides  initial  estimates  for  the  length  (and  hence  the 
project  cost  and  schedule)  which  are  refined  and  improved  as  the  design  pro¬ 
ceeds.  The  following  example  will  make  this  clearer. 


3.1.2  An  Example 

To  illustrate  this  method,  the  experiment  controller  example  of  section 
2.4  will  be  used.  The  input  and  output  data  items  for  each  node  in  the  design 
are  stored  in  the  DARTS  database,  so  that  it  is  a  simple  matter  to  determine 

H*  and  hence  V*.  For  this  example,  A  was  taken  to  be  1.3,  corresponding  to 

a  high  level  implementation  language.  The  data  for  design  one  are  presented 
in  Table  24,  and  for  design  two  in  Table  25. 

Referring  to  Table  24,  it  is  seen  that  when  the  counting  method  was 

applied  to  the  top  node  in  the  design  (component  1.1),  N  was  found  to  be  300.2 

which  corresponds  to  about  80  lines  of  source  code.  When  the  method  is 
applied  to  the  next  level  of  the  design,  and  the  lines  of  code  estimates  are 
totalled,  an  estimate  of  110  lines  of  code  is  obtained.  Similarly,  when  the 
method  is  applied  to  three  levels,  the  estimate  is  reduced  to  95  lines  of 
code. 

Referring  to  Table  25,  the  top  level  estimate  is  the  same,  namely,  80 
lines  of  code.  However,  the  second  and  third  level  estimates  are  165  and  167 
lines  respectively.  These  estimates  reinforce  the  conclusions  reached  earli¬ 
er,  namely,  that  design  two  is  more  complex  than  design  one.  Furthermore, 
they  provide  insight  into  the  relative  cost  of  implementing  the  two 
approaches.  The  result  is  especially  striking,  since  to  three  levels,  design 
two  has  only  six  components,  while  design  one  has  eleven. 

The  estimates  also  enable  the  designer  to  identify  the  sources  of  complex¬ 
ity  in  the  design.  When  estimates  jump  from  one  level  to  the  next  (as  with 
design  two),  it  signals  an  unexpectedly  large  increase  in  complexity.  The 
designer  can  then  identify  the  modules  which  most  contribute  to  the  complexi¬ 
ty,  and  determine  if  improvements  can  be  made. 

A  final  point  worth  mentioning  is  that  this  technique  depends  on  being 
able  to  determine  n*  and  hence  v*  for  designs  and  design  components.  In  par¬ 
ticular,  if  data  item  names  represent  abstractions  for  complicated  structures, 
the  number  of  unique  operands  needs  to  be  appropriatedly  increased.  This  can 
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Table  24.  Length  Estimates  for  Design  One 


Component 

n* 

V* 

n 

N 

KDSI 

Z  KDSI 

1.1 

13 

48.106 

60.9 

300.2 

0.080 

0.080 

1.1.1 

3 

4.755 

5.24 

7.3 

0.002 

0.110 

1.1.2 

5 

11.610 

11.6 

29.3 

0.008 

1.1.3 

14 

53.303 

69.6 

358. 

0.096 

1.1.4 

4 

8.000 

8.09 

16.3 

0.004 

1.1.1 

3 

4.755 

5.24 

7.3 

0.002 

0.095 

1.1. 2.1 

4 

8.000 

8.09 

16.3 

0.004 

1.1. 2. 2 

5 

11.610 

11.6 

'29.3 

0.008 

1.1. 3.1 

6 

15.510 

15.7 

46.6 

0.012 

1.1. 3. 2 

5 

11.610 

11.6 

29.3 

0.008 

1.1. 3. 4 

4 

8.000 

8.09 

16.3 

0.004 

1.1. 3. 5 

9 

28.529 

31.5 

125.3 

0.033 

1.1. 3. 6 

5 

11.610 

11.6 

29.3 

0.008 

1.1. 4.1 

4 

8.000 

8.09 

16.3 

0.004 

1.1. 4. 2 

5 

11.610 

11.6 

29.3 

0.008 

1.1. 4. 3 

4 

8.000 

8.09 

16.3 

0.004 

probably  be  done  without  too  much  difficulty,  but  further  experience  with  the 
technique  is  needed  in  order  suggest  practical  methods  for  handling  this  situ¬ 
ation. 


3.2  USE  OF  DESIGN  METRICS 


Although  design  metrics  can  be  used  whenever  design  information  is  avail¬ 
able,  major  improvements  in  being  able  to  monitor  and  influence  software  qual¬ 
ity  will  only  occur  when  design  tools  and  metrics  are  made  part  of  an 
integrated  software  engineering  environment.  The  various  Ada  Programming  Sup¬ 
port  Environments  (APSEs)  now  under  development  provide  an  ideal  opportunity 
for  application  of  these  techniques.  Although  the  metrics  would  provide 
information  of  primary  use  to  developers,  program  office  personnel  would, 
using  suitable  contract  clauses  and  data  item  descriptions,  be  able  to  request 
quality  status  information  at  periodic  intervals  based  on  information  in  the 
project  data  base.^  This  would  be  greatly  facilitated  if  standards  existed  for 
generating  the  required  information. 


108  Automating  Software  Design  Metrics 


Component 

n* 

V* 

n 

M 

KDSI 

I  KDSI 

2.1 

13 

48.106 

60.9 

300.2 

0.080 

0.080 

2.1.1 

6 

15.510 

15.7 

46.6 

0.012 

0.165 

2.1.2 

17 

69.487 

99.3 

559. 

0.149 

2.1.3 

4 

8.000 

8.09 

16.3 

0.004 

2.1.1 

6 

15.510 

15.7 

46.6 

0.012 

0.167 

2. 1.2.1 

10 

33.219 

38.0 

161.6 

0.043 

2. 1.2. 2 

14 

53.303 

69.6 

358. 

0.096 

2. 1.3.1 

4 

8.000 

8.09 

16.3 

0.004 

2. 1.3. 2 

5 

11.610 

11.6 

29.3 

0.008 

2.1'.3. 3 

4 

8.000 

8.09 

16.3 

0.004 

_ 

The  uses  of  design  metrics  in  the  three  earliest  phases  of  the  life  cycle 
can  be  outlined  as  follows: 

1.  Software  Requirements  Specification 

•  Requirements  are  generated  using  a  suitable  requirements  specifica¬ 
tion  language  or  tool.  If  the  requirements  are  expressed  as  a 
hierarchy  of  functions  with  inputs  and  outputs  specified  (as  per 
MIL-STD-483/490,  type  B5) ,  then  Halstead  metrics  can  be  applied. 
Alternatively,  it  is  possible  to  develop  a  Halstead  technique  using 
a  prose  requirements  specification,  adapting  the  form  used  in  Sec¬ 
tion  2. 5. 4. 4. 

•  These  metrics  would  be  used  to  generate  estimates  of  KDSI  for  com¬ 
parison  with  KDSI  estimates  generated  by  conventional  means. 

•  Particularly  complicated  functions  would  be  identified  for  risk 
assessment. 

•  Review  of  these  estimates  would  be  a  topic  included  at  the  Software 
Requirements  Review. 
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Architectural  Design 


Structured  analysis  (or  some  other  technique)  is  used  to  identify 
objects  for  a  DARTS  process-based  model,  or  an  Ada  object-oriented 
design.  The  design  is  entered  into  a  design  database.  At  fre¬ 
quent  and  periodic  intervals,  Halstead,  McCabe,  and  other  design 
metrics  are  applied  to  the  design  data. 


The  metrics  are  used  to  compare  different  design  approaches  in 
terms  of  complexity  and  impact  on  project  cost  and  schedule. 


The  metrics  are  used  to  identify  problematic,  overly  complex,  or 
inconcise  areas  of  the  design,  in  order  to  make  improvements. 


The  metrics  are  used  to  monitor  the  progress  of  the  design  as  time 
proceeds. 


Review  of  these  estimates  would  be  a  topic  included  at  the  Prelimi¬ 
nary  Design  Review. 


Detailed  Design 


The  detailed  design  would  proceed  as  a  refinement  of  the  architec¬ 
tural  design.  The  metrics  would  continue  to  be  used  in  a  similar 
fashion. 


Review  of  the  metrics  data  would  be  a  topic  included  at  the  Crit¬ 
ical  Design  Review. 


It  is  anticipated  that  the  chief  value  of  the  design  metrics  would  be  to 
call  attention  to  the  impact  of  design  decisions  as  they  are  made.  The  met¬ 
rics  would  supplement  but  in  no  way  replace  the  judgment  of  experienced  soft¬ 
ware  designers  and  managers.  The  ability  to  measure  the  impacts  of  design 
decisions  and  to  institute  corrective  actions  early  in  the  development  process 
would  be  a  sign  that  a  major  improvement  had  indeed  been  made  in  the  manner  in 
which  software  products  are  designed  and  implemented. 
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4.0  CONCLUSIONS 


This  research  effort  has  concluded  the  following. 

1.  Software  quality  can  be  assessed  early  in  the  life-cycle  with  metrics 
like  those  of  McCabe  and  Halstead.  The  collection  of  metric  data  can 
be  automated  and  captured  from  the  databases  of  design  tools  like 
DARTS.  However,  the  databases  must  contain  the  information  necessary 
for  metric  measurement  in  a  form  recognizable  by  the  design  tool.  For 
example,  control  flow  or  data  definitions  which  occur  in  free-form  text 
will  not  be  included  in  metric  calculation. 

2.  Out  of  the  approximately  100  McCall  metric  elements,  about  25%  are  good 
prospects  for  automatic  measurement  with  a  design  tool  like  DARTS. 
However,  manual  assistance  is  required  to  measure  most  criteria  in  the 
framework  since  the  criteria  contain  some  subjective  elements. 

3.  Metrics  that  measure  data  elements  or  some  aspect  of  data-flow  are  gen¬ 
erally  more  useful  than  those  that  deal  with  control  flow,  in  the  early 
design  phases.  Interfaces  between  software  components  are  typically 
defined  prior  to  the  internal  control  structure  of  the  components. 
This  would  include,  for  example,  Halstead's  metrics. 

4.  When  Halstead  metrics  are  used  during  design  and  the  Potential  Volume 
of  each  component  is  known,  alternative  counting  techniques  can  be 
developed  which  avoid  some  of  the  controversial  issues  surrounding  the 
Halstead  counting  technique. 

5.  Design  metrics  can  be  used  when  Ada  or  an  Ada  PDL  is  used  during 
design.  Ada  supersets,  like  Byron,  are  more  useful  than  Ada  itself 
during  architectural  design  due  to  their  ability  to  represent  abstract 
concepts  and  include  prose  commentary. 

6.  It  is  still  early  to  judge  the  utility  of  design  metrics.  Small  exam¬ 
ples  seem  to  work,  but  the  size  of  the  sample  used  for  validation  was 
too  small.  A  more  rigorous  validation  effort  might  be  set  up  as  fol¬ 
lows:  During  a  real  software  development  effort,  use  metrics  with  an 
automated  tool  and  sample  software  quality  at  frequent  intervals  during 
development  to  get  a  better  idea  of  how  useful  early  data  is  for  esti¬ 
mating  the  quality  of  delivered  software  products.  ' 

7.  A  methodology  has  been  presented  for  the  use  of  quality  metrics  during 
design.  In  particular,  it  is  possible  to  use  counts  of  operators  and 
operands  to  estimate  the  length  of  an  implementation  in  terms  of  deliv¬ 
ered  source  instructions.  From  this  parameter,  project  costs  and  sche- 
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As  this  study  has  shown,  design  metrics  have  the  potential  for  improving 
control  over  the  software  development  process.  This  section  lists  areas  in 
which  future  research  would  enhance  the  practicality  of  using  design  metrics. 

The  prime  need  is  for  verification  of  the  metrics  from  metric  data  col¬ 
lected  throughout  the  life-cycle  of  many  real  projects.  This  would  provide  a 
statistically  significant  database  from  which  equations  which  relate  metric 
values,  planning  parameters,  and  quality  factors  could  be  drawn.  The  examples 
provided  in  the  preceeding  text  indicate  that  the  metrics  could  prove  useful, 
but  they  exhibit  pathological  behavior,  such  as  extreme  sensitivity  to  small 
changes,  which  would  be  eliminated  with  a  larger  sample.  Incorporating  metric 
tools  into  an  APSE  would  encourage  data  collection. 

Another  area  where  work  is  needed  is  in  relating  the  Software  Quality 
Framework  to  other,  more  direct,  measures  of  the  quality  factors.  For  exam¬ 
ple,  reliability  as  measured  in  terms  of  mean  time  to  next  failure. 

This  research  identified  controversial  issues  surrounding  the  Halstead 
identification  and  counting  technique.  This  evidence,  as  well  as  other 
research,  establishes  the  need  to  develop  a  consistent  Halstead  counting  meth¬ 
od  for  use  throughout  design  to  deal  with  problems  where  the  Potential  Volume 
is  not  known. 

This  report  has  addressed  metric  measurement  of  design  complexity.  Met¬ 
rics  could  be  developed  which  evaluate  the  efficacy  of  the  design  procedures: 
how  the  development  methods  used  contribute  to  the  quality  factors.  Similar¬ 
ly,  quality  measurement  could  be  expanded  to  cover  the  entire  software,  and 
system  development  processes.  A  key  support  item  for  these  endeavors  is  an 
integrated  database  of  real  project  data,  from  planning  through  maintenance, 
with  data  collection  for  quality  evaluation  as  an  integral  part  of  the  proc¬ 
ess. 


Another  area  which  might  be  covered  in  more  depth  is  how  tradeoffs  among 
the  quality  factors  may  be  measured  and  evaluated.  This  task  was  within  the 
original  scope  of  this  project,  but  it  was  not  initiated  due  to  a  decision  to 
consider  Ada  design  metrics  in  detail. 

Work  should  be  undertaken  to  establish  the  best  use  of  requirements  and 
design  media  for  Ada.  Ada  has  growing  potential  as  a  software  design  aid 
itself.  This  task  should  consider  whether  a  restricted  subset  of  Ada,  Ada  as 
defined,  or  Ada  with  additional  features  (e.g.,  Byron)  is  more  useful  and 
appropriate  as  a  design  or  requirements  aid. 
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APPENDIX  A.  GLOSSARY  OF 


ACRONYMS  AND 


Ada  Programming  Support  Environment 


Automatic  Measurement  Tool 


Communications  of  the  ACM 


Control  Data  Corporation 


Critical  Design  Review 


COCOMO 


constructive  COst  MOdel 


Computer  Software  Component 


Computer  Software  Configuration  Item 


The  Charles  Stark  Draper  Laboratory,  Inc. 


DARTS 


Design  Aids  for  Real-Time  Systems 


Data  Item  Description 


Department  of  Defense 


Extended  Control  and  Simulation  Language 


Electronic  Systems  Division 


Higher  Order  Language 


Thousands  of  Delivered  Source  Instructions 


Program  Design  Language 


Preliminary  Design  Review 


Program  Evaluation  and  Review  Technique 


Quality  Assurance 


Rome  Air  Development  Center 


Software  Quality  Assurance 
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SRR  Software  Requirements  Review 

STARS  Software  Technology  for  Adaptable  and  Reliable  Systems 
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C3DL  "  DESIGN  AIDS 
FOR  RIAL-TIME  SYSTEMS 

plottree  (nxnj) 

DATABASE  IS  T19A 
OWNER  IS  AJR1302 


PACK  1 

DATE  22  MAR  1083 
TIME  180331 
TOPNODB  3 
ALL  GENERATIONS 


IP  QTT  GT  10 


f  IP  QTY  GT  200 


ELSE  BILLA  EQ  000; 


_ 3X1 

3 

T  GE  900 

ELSE 

ELSE  BILLA  EQ  BILLA 


+  000: 


Figure  17.  CAC!^ Example  14a,  DARTS  Representation 
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C.l  DESIGN  TREES 


Figure  21  is  the  design  tree  for  the  implementation,  in  DARTS,  of  the  Hal¬ 
stead  metric.  A  description  of  the  top  four  generations  of  nodes  follows. 


C.1.1  Node  9 
Processing 

The  Halstead  module  determines  the  Halstead  parameter  values  for  a 
user-specified  subtree  of  a  design  represented  as  a  DARTS  tree.  The 
user  also  selects  the  counting  method  employed. 


Input 


Database  representation  of  the  tree. 

User-specified  top  node  of  the  subtree  to  be  analyzed. 
User-specified  depth  of  the  subtree  to  be  analyzed. 
User-specified  counting  method. 


Output 


On  file  FLOERR,  the  subfee  designation  and  counting  method,  and  the 
parameter  values  for  the  subtree. 


C.l. 2  Node  9.1 


Processing 


This  node  represents  a  recursive  invocation  of  a  tree  traversal  mod¬ 
ule.  The  tree  traversal  module  visits  each  node  of  the  user-specified 
subtree,  collecting  the  numbers  of  operators  and  operands. 


Input 


Database  representation  of  the  tree. 
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Current  top  node  of  the  subtree  to  be  analyzed  (initially  the 
user-specified  top  node) . 

User-specified  depth  of  the  subtree  to  be  analyzed. 

User-specified  counting  method. 

Output 

List  of  operators  with  counts  for  each. 

List  of  operands  with  counts  for  each. 

C.1.3  Node  9.1.1 
Processing 

This  node  selects  a  counting  routine  to  call  depending  on  which  count¬ 
ing  method  the  user  specified. 

Input 

User-specified  counting  method. 

Output 

C.1.4  Node  9. 1.1.1 
Processing 

This  module  implements  the  simple  counting  method  in  which  the  vari¬ 
ables  in  the  INDATA  and  OUTDATA  lists  are  counted  as  operands. 

Input 

Database  representation  of  the  tree, 

List  of  operators  with  counts  for  each. 

List  of  operands  with  counts  for  each. 

Output 

List  of  operators  with  counts  for  each, 

List  of  operands  with  counts  for  each. 
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C.1.5  Node  9.1. 1.2 


Processing 

This  module  implements  the  uninterpreted  counting  method  in  which 
nodes  are  differentiated  as  being  function  or  decision  nodes,  but  the 
node  tabs  are  ignored.  For  function  nodes,  the  variables  in  the  INDA¬ 
TA  and  OUTDATA  lists  are  counted  as  operands.  For  decision  nodes,  the 
variables  in  the  PREDVAR  lists  are  counted  as  operands. 

Input 

Database  representation  of  the  tree. 

List  of  operators  with  counts  for  each. 

List  of  operands  with  counts  for  each. 

Output 

List  of  operators  with  counts  for  each. 

List  of  operands  with  counts  for  each. 


C.1.6  Node  9. 1.1. 3 


Processing 

This  module  implements  the  interpreted  counting  method,  based  on  the 
specification  in  Section  2. 3. 2. 2,  in  which  the  node  tabs  are  scanned 
for  instances  of  operators  and  operands.  INDATA,  OUTDATA  and  PREDVAR 
lists  are  used  to  determine  counts  of  operators  and  operands.  The 
details  of  this  processing  are  shown  in  Part  2  of  Figure  21  on  page 
126 

Input 

Database  representation  of  the  tree. 

List  of  operators  with  counts  for  each. 

List  of  operands  with  counts  for  each. 

Output 

List  of  operators  with  counts  for  each. 
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List  of  operands  with  counts  for  each. 


C.1.7  Node  9.2 


Processing 

This  node  adds  the  occurrences  of  flow-of-control  to  the  operator 
count,  and  calculates  the  Halstead  parameters  from  the  basic  operator 
and  operand  counts. 

Input 

List  of  operators  with  counts  for  each. 

.  List  of  operands  with  counts  for  each. 

Output 

Halstead  parameter  values. 


C.1.8  Node  9.2.1 
Processing 

This  node  calculates  the  number  of  flow-of-control  instances  from  the 
number  of  nodes. 

Input 

Number  of  nodes  traversed. 

Output 

r 

Number  of  flow-of-control  transfers. 

C.1.9  Node  9.2.2 
Processing 

This  node  adds  "CTL"  to  the  list  of  operators. 

Input 

List  of  operators. 
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Output 


List  of  operators. 


C.1.10  Node  9.2.3 


Processing 

This  node  adds  the  number  of  f low-of -control  instances  to  the  number 
of  operators  accumulated  for  the  subtree,  depending  on  the  counting 
method  being  used. 

Input 

Number  of  flow-of-control  transfers. 

List  of  operators  with  counts  for  each. 

Output 

List  of  operators  with  counts  for  each. 


C.1.11  Node  9. 2. 3.1 
See  Node  9. 1.1.1. 

C.1.12  Node  9. 2. 3. 2 
See  Node  9. 1.1. 2. 

C.1.13  Node  9.2.4 
Processing 

This  node  calculates  the  Halstead  parameters  from  the  basic  operator 
and  operand  counts. 

m 

Input 

List  of  operators  with  counts  for  each. 

List  of  operands  with  counts  for  each. 


Appendix  C.  DARTS  PL/I  Halstead  Modules 


129 


Output 


Halstead  parameter  values. 


C.1.14  Node  9.3 


Processing 

This  node  writes  the  Halstead  parameters  in  tabular  form  onto  the  out¬ 
put  file. 

Input 

Halstead  parameter  values. 

Output 

On  file  FLOERR,  the  subtree  designation  and  counting  method,  and  the 
parameter  values  for  the  subtree. 
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APPENDIX  D.  DARTS  PL/I  MCCABE  MODULES 


D.l  DESIGN  TREES 


Figure  22  shows  four  levels  of  the  design  tree  for  the  implementation,  in 
DARTS,  of  the  McCabe  metric.  A  description  of  each  node  follows. 


D.1.1  Node  2 


Processing 

The  McCabe  subtree  determines  the  McCabe  metric  interval  bounds  for  a 
user-specified  subtree  of  a  design  represented  as  a  DARTS  tree.  The 
user-specified  subtree  is  a  module  by  definition,  for  this  metric 
evaluation.  A  module  info  data  area  is  created  and  stacked  whenever  a 
module  is  encountered  in  the  user-specified  subtree,  as  indicated  by 
"BLK"  or  "SEG"  in  the  node*&  tab.  When  the  end  of  the  module  is 
encountered,  an  output  line  is  created  from  the  data  in  the  module 
info  data  area,  and  the  data  area  is  popped  off  the  stack  and 
destroyed.  Running  totals  of  the  numeric  quantities  are  kept  for  the 
subtree  being  analyzed.  They  are  printed  at  the  end  of  the  process¬ 
ing. 

Input 

Database  representation  of  the  tree. 

User-specified  top  node  of  the  subtree  to  be  analyzed. 

User-specified  depth  of  the  subtree  to  be  analyzed. 

Output 

On  file  FLOERR,  the  module  name,  number  of  decisions,  number  of  simple 
predicates  and  metric  interval  '  j.-.ues  for  each  module  encountered,  and 
the  total  metric  interval  value  for  the  user-specified  subtree.  Mod¬ 
ules  which  are  invoked,  but  not  present  in  the  subtree,  are  tagged 
with  a  message  instead  of  the  metric  interval  valile.  This  information 
shares  file  FLOERR  with  the  Halstead  metric  output,  but  each  function 
starts  a  new  page  when  invoked. 
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D. 1.2 -Mode  2.10 


Processing 


The  Initialize  subtree  starts  the  output  with  a  page  header  on  a  new 
page. 

Input 

None. 

Output 

Page  header  on  file  FLOERR. 


D.1.3  Node  2.20 


Processing 

The  Traverse  subtree  subtree  visits  each  node  of  the  user-specified 
subtree,  collecting  the  metric  data,  and  making  the  output  lines.  It 
also  collects  lists  of  the  modules  which  occur  in  the  subtree,  and  the 
modules  which  are  referenced  in  the  subtree. 

Input 

Database  representation  of  the  tree. 

User-specified  top  node  of  the  subtree  to  be  analyzed. 

User-specified  depth  of  the  subtree  to  be  analyzed. 


r-v 

V 

■-y. 


v_v 


Output 

Linked  list  of  output  lines  for  each  module  which  occurs  in  the  sub¬ 
tree,  alphabetically  ordered  by  the  module  name.  Each  output  line 
contains  the  module  name,  the  number  of  decisions,  the  number  of  sim¬ 
ple  predicates,  and  the  metric  interval  value. 

List  of  modules  invoked  in  the  subtree,  in  reverse  of  the  order  in 
which  they  are  detected. 
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D.1.4  Node  2.20.10 


Processing 


The  Node  visit  1  subtree  determines  whether  this  node  starts  a  module, 
whether  it  infvokes  a  module,  the  number  of  decisions  (possibly  complex 
predicates)  for  the  node,  and  the  number  of  simple  predicates  for  the 
node. 

Input 

Database  representation  of  the  tree. 

Current  module  info  data  area. 

List  of  modules  invoked  in  the  subtree. 

Output 

Current  module  info  data  area. 

List  of  modules  invoked  in  the  subtree. 


D.1.5  Node  2.20.10.10 
Processing 

The  Get  module  pred  info  from  tab  subtree  determines  whether  this  node 
starts  a  module,  whether  it  invokes  a  module,  the  number  of  decisions 
(possibly  complex  predicates)  for  the  node,  and  the  number  of  simple 
predicates  for  the  node.  It  also  adds  items  to  the  list  of  invoked 
modules,  if  this  node  invokes  any.  If  there  is  a  tab  on  the  node,  it 
gets  the  information  from  the  tab.  If  there  is  no  tab,  the  node  does 
not  start  or  invoke  a  module;  the  number  of  decisions  is  determined  by 
the  node  type  and  number  of  offspring;  and  the  number  of  predicates  is 
the  same  as  the  number  of  decisions. 

• 

Input 

Database  representation  of  the  tree. 

Current  module  info  data  area. 

List  of  modules  invoked  in  the  subtree. 
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Output 


Current  module  info  data  area. 


List  of  modules  invoked  in  the  subtree. 


.1.6  Mode  2.20.10.20 


Processing 


The  New  module  processing  subtree  creates  and  initializes  a  new  module 
info  data  area  if  this  node  starts  a  module. 


Input 


Current  (old)  module  info  data  area. 


Output 


Current  (new)  module  info  data  area. 


.1.7  Node  2.20.10.40 


Processing 


The  Accumulate  for  this  subtree  subtree  adds  the  numbers  of  decisions 
and  predicates  for  this  node  to  the  numbers  of  decisions  and  predi¬ 
cates  accumulating  for  the  current  module. 


Input 


r.* 


Current  module  info  data  area. 


Output 


Current  module  info  data  area. 


*  v-,' 

vjv*  j 

m 


.1.8  Node  2.20.20 


Processing 


The  ^averse  offspring  subtrees  subtree  recursively  calls  the  traverse 
subtree  module  for  each  of  the  offspring  of  the  current  node. 


w  ♦  .  ^ 

.\yW 
* « » 
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Input 


User- specified  top  node  of  the  subtree  to  be  analyzed. 

User-specified  depth  of  the  subtree  to  be  analyzed. 

Output 

Linked  list  of  output  lines  for  each  module  which  occurs  in  the  sub¬ 
tree,  alphabetically  ordered  by  the  module  name.  Each  output  line 
contains  the  module  name,  the  number  of  decisions,  the  number  of  sim¬ 
ple  predicates,  and  the  metric  interval  value. 

List  of  modules  invoiced  in  the  subtree,  in  reverse  of  the  order  in 
which  they  are  detected. 


D.1.9  Node  2.20.30 
Processing 

<*• 

The  Node  visit  2  subtree  does  any  processing  necessary  at  the  return 
through  the  node.  In  this  case,  it  turns  the  current  module  info  data 
into  an  output  line;  destroys  the  current  module  info  data  area;  and 
adds  the  numeric  quantities  for  this  subtree  to  those  accumulating  for 
the  total  line,  if  this  node  is  the  end  of  a  module. 

Input 

Current  module  info  data  area. 

Totals  data  area. 

Output 

Output  line  for  the  current  module,  containing  the  module  name  and 
metric  interval  value. 

Totals  data  area. 


D.1.10  Node  2.20.30.10 
Processing 

7 «e  Make  output  line  and  cleanup  subtree  turns  the  current  module  info 
data  into  an  output  line;  destroys  the  current  module  info  data  area; 
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and  adds  the  numeric  quantities  for  this  subtree  to  those  accumulating 
for  the  total  line,  if  this  node  is  the  end  of  a  module. 

Input 

Current  module  info  data  area. 

Totals  data  area. 


mi 

Output 

K 

Output 

line  for  the 

r  ■ 

metric 

interval  value 

F:> 

CMHil 

Totals 

data  area. 

tt'v-t: 


b 


D.l.ll  Node  2.30 
Processing 


The  Compare  SEG  vs  INV  subtree  creates  an  output  line  for  every  module 
which  was  invoked  but  not  present  in  the  subtree. 

Input 

List  of  output  lines  for  modules  present  in  the  subtree. 

List  of  modules  invoked  in  the  subtree. 

Output 

List  of  output  lines  for  modules  present  in  the  subtree,  with  an  out¬ 
put  line  added  for  each  module  which  is  invoked,  but  not  present,  in 
the  subtree.  The  added  lines  contain  the  module  name  and  a  footnote 
reference  number. 

Flag  indicating  that  the  footnote  message  to  that  effect  should  be 
printed . 


D.1.12  Node  2.40 


Processing 


Or. 


I 

V“. 

■  Tji 


The  Cleanup  subtree  makes  the  total  output  line  for  the  subtree  ana¬ 
lyzed  . 
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Totals  data  area 


Output 


Totals  output  line. 


D.1.13  Node  2.50 


Processing 


The  Format  output  subtree  writes  the  module  and  total  output  lines  to 
the  FLOERR  file. 


Input 


Linked  list  of  output  lines  for  each  module  which  occurs  or  is  invoked 
in  the  subtree,  alphabetically  ordered  by  the  module  name. 

Totals  output  line. 

Footnote  flag. 


Output 


On  file  FLOERR,  the  module  name,  number  of  decisions,  number  of  simple 
predicates  and  metric  interval  values  for  each  module  encountered,  and 
the  total  metric  interval  value  for  the  user-specified  subtree.  If 
indicated  by  the  flag,  the  "invoked  but  not  present"  footnote  is 
printed. 
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Table  26.  Data-Flow  Table  -  Design  1  (Part  1  of  2) 


CSOL  **  DESIGN-AIDS 

FOR  REAL-TIME  SYSTEMS 

OATA  FLON  TABLE 

TOPNOOE  ID)  1.1 

ILL  GEtC  RATIONS 

DATABASE  ISl  SAMPLE 

USER  ISi  AJRlStt 

PAGE  1 

DATE:  00  SEPT  198 
TIME:  11:21:39 

TOPNOOE:  EXPERIMENT  CONTROLLER  1 


INDATA:  EXP.TABLE 
EXP.COUNT 
•INT_B 
•IMT.T 
•INT  U 
SENSOR_DATA 


OUTDATA:  •INTERVAL 
•STOP 
•STEP.CMD 
•REPORT 
•EXP.STATUS 


INITIALIZATION 


GET  CELL  OATA  1 


MEASURE  1 


CONTROL  EACH  EXPERIMENT 


INITIALIZE  EXPERIMENT 


•SENSOR  OATA  I  SUPPLIED 


EXP.TABLE 


INITIALIZATION 

• 

GET  CELL  DATA  1 

MORE  EXPERIMENTS 


OUTPUTS 


RESULTS.T  ABLE  MEASURE  1 


SENSOft.DATA 


RESULTS  TABU  I  MEASURE  2 


I  POSITION  BURETTE 


POSITION  BURETTE 


TAKE  MEASUREMENTS 
I  TEST  MEASURE 


START  TIMER 


SEM)  MOTOR  COMUND 


NAXT  FOR  BURETTE  INIT 


ENOUGH 


START  TIMER 


TAKE  MEASUREMENTS 


MAIT  FOR  TIMER  INIT 


GET  CELL  DATA  Z 


•STEP.CMO 


INITIALIZE  EXPERIMENT 


INITIALIZE  EXPERIMENT 
TEST  MEASURE 


•SEMSOR.OATA  I SUPPLIED 


lui.uLiJj  wmr, 


POSITION  BURETTE 
ENOUGH 


I  SENSOR.DAT A  MEASURE  2 


ii.iinjinar 


Table  27.  Data-Flow  Table  -  Design  2  (Part  1  of  2) 


INITIALIZATION 


|RESULTS_TABLE  MEASURE 
$  COMPUTE  2 


NEH_EXP 

READINGS 


PREPARE  FOR  MEASUREMENT 
FIRSTTINE  OR  NEN  EXP 
POST  MEASURE  PROCEDURE 

PREPARE  FOR  MEASUREMENT 

TAKE  MEASUREMENTS 
TEST  MEASURE 


CONTROL  EACH  EXPERIMENT 
PREPARE  FOR  MEASUREMENT 


FIRSTTM  OR  KM  EXP 

CONTINUE 

INITIALIZE  EXPERIMENT 


EXP.COUNT 

FIRSTTIME 


MORE  EXPERIMENTS 

INITIALIZATION 
SET  FLAGS 

INITIALIZATION 
INITIALIZE  EXPERIMENT 
SET  FLAGS 
NEN  EXPERIMENT 

INITIALIZATION 
SET  FLAGS 


|EXP_TARLE 


NEH_EXP 

STEPS 


PREPARE  FOR  MEASUREMENT 


I  POSITION  BURETTE 
I  ENOUGH 


TAKE  MEASUREMENTS 
TEST  MEASURE 


START  TIMER 
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CSOL  **  DESIGN- AIDS 

TOPNOOE  ID t  2.1 

PAGE  2 

FOR  REAL-TIME  SYSTEMS 

ALL  GENERATIONS 

DATE:  OB  SEPT  196 

OATA  FLOM  TABLE 

DATABASE  IS:  SAMPLE 

USER  IS:  AJR1592 

TIME:  11:22 ',<7 

SEND  MOTOR  COttlAND 


NUT  FOR  BURETTE  IMT 


START  TIMER 


HAIT  FOR  TIMER  INIT  1 


NAIT  FOR  TIMER  INT  2 


TARE  MEASUREMENTS 


GET  CELL  DATA 


POST  MEASURE  PROCEOURE 


SET  FLAGS 


CHECK  FOR  USER  INTERRUPT 


USER  INTERRUPT  PROCEOURE 


COMPUTE  1 


LIST  1 


SC NO  LIST  TO  PRINTER  1 


INITIALIZE  EXPERIMENT 
ENOUGH 


INITIALIZE  EXPERIMENT 
ENOUGH 


[INITIALIZE  EXPERIMENT 


[supplied 


[supplied 


INITIALIZATION 
INITIALIZE  EXPERIMENT 
TEST  MEASURE 


INITIALIZATION 


GET  CELL  OATA 


1  INITIALIZATION 
SET  FLAGS 


OINZTJU  I SUPPLIED 


I USE R_ INTERRUPT  CHECK  FOR  USER  INTERRUPT 


I  RESULTS JTABLE 


I  INTERVAL 


| f INIT_T 


I  tINT_T 


(•SENSOR.OATA 


|  POSITION  BURETTE 


[requested 


COMPUTE  1 


LIST  X 


| RESULTS  TABLE  MEASURE 

COMPUTE  1 
LIST  X 
CCX1HJTE  2 
LIST  2 


PREPARE  FOR  MEASUREMENT 
FIRSTTIME  OR  HEM  EXP 
POST  MEASURE  PROCEOURE 

PREPARE  FOR  MEASUREMENT 


| USER_INTERRUPT  USER  INTERRUPT  PROCEDURE 


STATISTICS 


EXP.STATUS  SEND  LIST  TO  PRINTER  1 

I 


|*EXP_STATUS  REQUESTED 


LIST  OF  REFERENCES 


l-Tn-; 

v-.\ 

tv.*; 

L'  -  ' 
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.'V 
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to 


,\\\ 


[Boe  8l]  Boehm,  B.  W. ,  Software  Engineering  Economics,  Prentice-Hall, 
Englewood  Cliffs,  N.J.  07632,  1981. 

[Boe  83a]  Boeing  Aerospace  Company,  "Guidebook  for  Software  Quality  Meas¬ 
urement,"  Vol.  II,  February,  1983. 

[Boe  83b]  Boeing  Aerospace  Company,  "Software  Interoperability  and  Reusa¬ 
bility,"  Vol.  I,  March,  1983. 

[Boo  83]  Booch,  Grady,  Software  Engineering  with  Ada,  The  Benja¬ 

min/Cummings  Publishing  Company,  Inc.,  1983. 

[cai  75]  Caine,  Stephen  H.,  and  E.  Kent  Gordon,  1975.  "PDL — A  Tool  for 
Software  Design,"  AFIPS  Conference  Proceedings  Vol.  44,  1975  National  Computer 
Conference . 

[Cai  77]  Caine,  Farber,  and  Gordon,  "PDL  Program  Design  Language  Reference 
Guide,"  Version  3,  February,  1977. 

[Cho  78]  Chow,  T.S.,  "Testing  Software  Design  Modeled  by  Finite-State 

Machines,"  IEEE  Transactions  on  Software  Engineering  Vol.  SE-4,  No.  3,  May 
1978,  pp. 105-109. 

[cou  83]  Coulter,  N.S.,  "Software  Science  and  Cognitive  Psychology"  IEEE 
Transactions  on  Software  Engineering  Vol.  SE-9,  No.  2,  March  1983,  pp. 166-171. 

[CSDL82]  The  Charles  Stark  Draper  Laboratory,  Inc.,  12  January  1982. 

Design  Aids  .for  Real-Time  Systems  (DARTS);  A  User's  Guide,  Version  3. 
CSDL-C-5441,  Cambridge,  MA.  January,  1982. 

[DoD  82a]  Department  of  Defense,  "Strategy  for  a  Software  Initiative,"  1 
October,  1982. 

[DoD  82]  MIL-STD-SDS  Joint  Logistics  Commanders,  Proposed  Military  Stand¬ 
ard  on  Defense  System  Software  Development,  and  attached  Data  Item 
Descriptions,  15  April,  1982. 

R-DID-107  Software  Requirements  Document 
R-DID-110  Software  Top  Level  Design  Document 
R-DID-111  Software  Detailed  Design  Document 

[DoD  83]  Department  of  Defense,  "Software  Technology  for  Adaptable,  Reli¬ 
able  Systems  (STARS)  Program  Strategy,"  1  April,  1983. 


\ 

\ 

•j 

•j 


List  of  References  145 


*»“ 


[Els  78]  Elshoff,  J.  L.,  "An  Investigation  into  the  Effects  of  the  Count¬ 
ing  Method  Used  on  Software  Science  Measurements,"  SI GPL AN  Notices,  Vol.  13, 
No.  2,  pp.  30-45,  February,  1978. 


[Fit  78]  Fitzsimmons,  A.,  and  T.  Love,  "A  Review  and  Evaluation  of  Soft¬ 
ware  Science,"  ACM  Computing  Surveys,  Vol.  10,  No.l,  pp.  3-18,  March,  1978. 

[Fur  8l]  Furtek,  F.  C.,  J.B.  DeWolf,  and  P.  Buchan,  "DARTS:  A  Tool  for 
Specification  and  Simulation  of  Real-Time  Systems,"  Proceedings  of  the  AIAA 
Computers  in  Aerospace  III  Conference,  October,  1981. 


[Gaf  81]  Gaffney,  J.  E., 
ware  Development  Management,” 


Jr.,  "Software  Metrics:  A  Key  to  Improved  Soft- 


Computer  Science  and  Statistics,  Proc.  13th  Sym¬ 


posium  on  the  Interface  1981,  Springer-verlag,  New  York,  pp.  211-220. 


[Gor  83]  Gordon,  M.,  "The  Byron  Program  Development  Language,"  Journal  of 
Pascal  and  Ada,  pp.  24-28,  May/June  1983. 


[Gor  79]  Gordon,  R.  D.,  "Measuring  Improvements  in  Program  Clarity",  IEEE 
Trans.  Software  Engineering,  Vol.  SE-5,  pp.  79-90,  March,  1979. 


[Hal  77]  Halstead,  M.  H.,  Elements  of  Software  Science,  Elsevier  North 

Holland,  Inc.,  Operating  and  Programming  Systems  Series,  New  York,  1977. 


[Hal 77a]  Halstead,  M.  H.,  "A  Quantitative  Connection  Between  Computer  Pro¬ 
grams  and  Technical  Prose,"  Proceedings  of  Fall  COMPCON  1977,  pp.  332-335. 

[Hal  78]  Halstead,  M.  H.  "Management  Prediction  -  Can  Software  Science 
Help?"  Proceedings  IEEE  CQMPSAC  78  (2nd  International  Computer  Software  and 
Applications  Conference),  1978,  pp  126-128. 

[Hal  78a]  Halstead,  M.  H.  "Software  Science  —  A  Progress  Report,"  Second 
Software  Life  Cycle  Management  Workshop,  Atlanta,  GA,  August,  1978,  pp. 
174-179. 


[Ham  82]  Hamer,  P.G.  and  G.D.  Frewin,  "M.H.  Halstead's  Software  Science  - 
A  Critical  Examination,"  Proc.  of  the  Sixth  International  Conference  on  Soft¬ 
ware  Engineering , ,  Tokyo,  Japan,  pp.  197-205,  September  1982. 

[Ker  74]  Kernighan,  B.  W.,  and  P.J.  Plauger;  "Programming  Style:  Examples 
and  Counterexamples,"  ACM  Computing  Surveys,  Vol.  6,  pp.  303-319,  December, 
1974. 


[McC  .76]  McCabe,  T.  J.,  "A  Complexity  Measure",  IEEE  Transactions  on  Soft¬ 
ware  Engineering,  Vol.  SE-2,  pp  308-320,  December,  1976. 


146 


Automating  Software  Design  Metrics 


[McC  80]  McCall,  J.  A.,  and  M.  Masumoto,  Software  Quality  Metrics  Enhance¬ 
ments,  RADC-TR-80-109 ,  Rome  Air  Development  Center,  1980. 

[McC  77]  McCall,  T.  J.,  P.  K.  Richards  and  G.  F.  Walters,  Factors  in  Soft¬ 
ware  Quality,  GE  Technical  Information  Series  77CIS02,  June,  1977. 

[McC  79]  McCall,  T.  J.,  and  M.  T.  Matsumoto,  Software  Quality  Metrics 
Enhancements  Final  Report,  September,  1979. 

[Men  75]  Mendelbaum,  H.G.,  and  F.  Madaule,  "Automata  as  Structured  Tools 
for  Real-Time  Programming,"  Proc.  of  the  1975  IFAC-IFIP  Workshop  on  Real-Time 
Programming  ,  Pittsburg,  PA.  August,  1975,  pp.  59-65. 

[Mye  77]  Myers,  G.  J.,  "An  Extension  to  the  Cyclomatic  Measure  of  Program 
Complexity",  SIGPLAN  Notices,  The  Association  for  Computing  Machinery,  Inc., 
pp  61-64,  October,  1977. 

[San  83]  San  Antonio,  R.  c.,  and  K.  L.  Jackson,  "Application  of  Software 
Metrics  During  Early  Program  Phases,”  Pro c.  of  NS I A  OSD  Conference,  Washing¬ 
ton,  D.  C.,  February,  1983. 

[She  83]  Shen,  V.Y.,  s.D.  Conte,  and  H.E.  Dunsmore,  "Software  Science 
Revisited:  A  Critical  Analysis  of  the  Theory  and  Its  Empirical  Support,"  IEEE 
Transactions  on  Software  Engineering  Vol.  SE-9,  No.  2,  March  1983,  pp. 155-165. 

[Szu  80]  Szulewski,  P.  A.,  M.H.  Whitworth,  P.  Buchan,  and  J.B.  Dewolf,  Qual¬ 
ity  Assurance  Guidelines  and  Quality  Metrics  for  Embedded  Real-Time  Software 
Designs,  CSDL-R-1376,  The  Charles  Stark  Draper  Laboratory,  Inc.,  May,  1980. 

[Szu  8l]  Szulewski,  P.  A.,  M.H.  Whitworth,  P.  Buchan, and  J.B.  Dewolf,  "The 
Measurement  of  Software  Science  Parameters  in  Software  Designs,"  ACM  SIGME- 
TRICS  Performance  Evaluation  Review,  Vol.  10,  No.  1,  Spring,  1981. 

[Tau  77]  Tausworthe,  Robert  C.,  Standardized  Development  of  Computer  Soft¬ 
ware,  Prentice-Hall,  Englewood  Cliffs,  New  jersey,  1977. 

[Tei  77]  Teichrow,  D.,  and  E.  Hershey,  "PSL/PSA:  A  Computer-Aided  Tech¬ 
nique  for  Structure  Documentation  and  Analysis  of  Information  Processes  Sys¬ 
tems,"  IEEE  Transactions  on  Software  Engineering,  vol.  SE-3,  No.  1,  pp  41-48, 
January,  1977. 

[Weg  82]  Wegner,  P.,  "Ada  Education  and  Technology  Transfer  Activities," 
ACM  Ada  Letters,  September,  1982. 


List  of  References 


14 


BIBLIOGRAPHY 


Barnes,  J.  G.  P.,  Programming  in  Ada,  Addison-Wesley,  1982. 


Beser,  Nicholas,  "Foundations  and  Experiments  in  Software  Science",  ACM 
SIGMETRICS  Performance  Evaluation  Review,  Vol.  11,  No.  3,  Fall  1982,  pp 
48-72. 

U.  S.  Department  of  Defense,  Ada  Programming  Language , 
ANSI/MIL-STD-1815A-1983 ,  22  January  1983,  American  National  Standards 
Institute,  Inc.,  New  York  NY  10018. 

Downes,  V.  A.  and  S.J.  Goldsack,  Programming  Embedded  Systems  with  Ada, 
Prentice/Hall,  1982. 

Gilb,  T.,  Software  Metrics ,  Winthrop  Publishers,  Inc.,  Computer  Systems 
Series,  Cambridge,  MA.,  1976. 

Gross,  D.  R.,  M.  A.  King,  M.  R.  Murr  and  M.  R.  Eddy,  "Complexity  Measure¬ 
ment  of  Electronic  Switching  System  (ESS)  Software",  ACM  SIGMETRICS  Per¬ 
formance  Evaluation  Review,  Vol.  11,  No.  3,  Fall  1982,  pp  75-85. 

Hartman,  S.  D.,  "A  Counting  Tool  for  RPG" ,  ACM  SIGMETRICS  Performance 
Evaluation  Review,  Vol.  11,  No.  3,  Fall  1982,  pp  86-100. 

Howden,  w.  E. ,  " Contemporary  Software  Development  Environments",  communi¬ 
cations  of  the  ACM,  Vol.  25,  No.  5,  May  1982  pp  318-329. 

IIT  Research  Institute,  "Software  Engineering  Research  Review:  Quantita¬ 
tive  Software  Models,",  order  no.  SRR-i,  Data  &  Analysis  Center  for  Soft¬ 
ware  (DACS) ,  Rome  Air  Development  Center,  Griffiss  AFB,  New  York,  1979. 

Intermetrics  Incorporated,  Byron  Reference  Manual,  Cambridge,  MA  02138, 
August ,  1983 . 

Laurmaa,  Timo  and  Markku  Syrjanen,  "APL  and  Halstead's  Theory:  a  Measur¬ 
ing  Tool  and  Some  Experiments",  ACM  SIGMETRICS  Performance  Evaluation 
Review,  Vol.  11,  No.  3,  Fall  1982,  pp  32-47. 

Naib,  F.  A.,  "An  Application  of  Software  Science  to  the  Quantitative  Mea¬ 
surement  of  Code  Quality",  ACM  SIGMETRICS  Performance  Evaluation  Review, 
Vol.  11,  No.  3,  Fall  1982,  pp  101-128. 


Bibliography  149 


(13)  Schnurer,  K.  E.,  "Product  Assurance  Program  Analyzer  (P.A.P.A.)  A  Tool 
for  Program  Complexity  Evaluation  (abstract  only)",  ACM  SIGMETRICS  Per¬ 
formance  Evaluation  Review,  Vol.  11,  Ho.  3,  Fall  1982,  pp  73-74. 

(14)  Yourdon,  Edward  and  L.  L.  Constantine,  Structured  Design:  Fundamentals 
of  a  Discipline  of  Computer  Program  and  Systems  Design,  Prentice-Hall, 
Englewood  Cliffs,  New  Jersey,  1977. 


Automating  Software  Design  Metrics 


MISSION 

of 

Rome  Air  Development  Center 

RAVC  plans  and  executes  research,  de.veZopme.nt,  tut  and 
selected  acquisition  programs  Zn  support  oh  Command,  Control 
Communications  and  Intelligence  (C3 1)  activities .  Technical 
and  engineering  support  within  areas  oh  technical  competence 
is  provided  to  ESV  Program  Ohhic.es  IPOs)  and  other  ESV 
elements.  The  principal  technical  mission  areas  are 
communications,  electromagnetic  guidance  and  control,  sur¬ 
veillance  oh  ground  and  aerospace  objects,  intelligence  data 
collection  and  handling,  inhormation  system  technology, 
ionospheric  propagation,  solid  state  sciences,  microwave 
physics  and  electronic  reliability,  maintainability  and 
compatibility. 


